> -----Original Message----- > From: Uli Mayring [mailto:[EMAIL PROTECTED] > Sent: den 26 november 2001 00:42 > To: Avalon Developers List > Subject: Re: unsubscribing for now > > > On Sun, 25 Nov 2001, Stefano Mazzocchi wrote: > > > Keep up the great work and, as a suggestion, avoid flexibility syndrome > > like the plague :) > > To quote Stefano from another posting: > > "Flexibility Syndrome is when you add another dimension to your solution > space to fit a new problem without trying to rotate your previous > solution space versors to cover the new problem." > > I don't know what a "versor" is, neither does my dictionary, but > probably something like an axis. A less polite way to put it would be > "change your problem to fit our solution" or "when your only tool is a > hammer, a lot of problems look like nails" ;-)
Or, "avoid adding features when you can solve the problem with the existing feature set." > Seriously, the world is not just black and white. Everything has its > advantages and its drawbacks. It seems to me that one of the drawbacks of > IoC is a loss in flexibility. We all remember the logging discussions :) I'd say IoC promotes flexibility like nothing else I've ever seen. As far as the logging discussions go, I say Berin *restored* IoC in logging by adding the Logger interface and abstracting away from the actual logging implementation. Before, the component actually demanded from the container to get a LogKit logger. This is similar to a Composable that demands an ExcaliburComponentManager instead of just any ComponentManager. (Either way, the Logger interface solved a massive amount of issues for me.) > I agree with Stefano: break IoC once and it becomes useless. IoC is an > authoritative design pattern and it loses its advantages, if it loses its > authority. So the question is: shall we use it and live with the drawbacks > or shall we use another design pattern? I don't see any drawbacks. The only complaint I've seen is performance considerations with wrapper classes, but as far as I know, everything other API have been successfully turned into a Component. > So far things look good, but > isn't it a pain in the ass, when you cannot just implement something you > need because of IoC? :) I can not think of anything that would result in not being able to implement something due to IoC. Basically, IoC is, as someone (forgot name) stated, about a container H, a component C and a resource R. If H can intercept C's request for R, we have IoC. In cases where the underlying API does not support IoC, such as when dealing with SAXParserFactory etc., this can be hidden inside a component. /LS -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
