Glen Mazza wrote: > --- Victor Mote <[EMAIL PROTECTED]> wrote: > > > > If I'm going to give up encapsulation or Separation > > of Concerns, or whatever > > you want to call it, what do I get in return? > > > > IMO you're not "giving up" SoC, you're gaining it: > > The > "manager<-->A<-->B<-->C<-->D<-->customer model" > keeps the business logic inherent to each object's > duties within each object. > > The other model, in which the manager sticks his > fingers in various parts of the process in every > object, is what I consider to break encapsulation.
We must be talking about two different things here. Does the Bourne shell "stick his fingers" into sed when I pipe from grep to sed to wc? In your model, grep has to know to pass to sed, which has to know to pass to wc. Single-purpose, can't be reused for anything else. Does Cocoon "stick his fingers" into Xalan when I use it to convert semantic XML to XSL-FO to PDF. No. In your model, Xalan is only usable in that context. Can't use it to convert to HTML. > > I give > > up reusability, > > Not necessarily--going back to the bakery example > (where reusability = hirability externally), Employee > A fully knows how to buy the bread, B knows how to > make the dough, C knows how to cook it, etc. They are > all very smart, self-contained objects. Nope. Reusability is = being able to hire them out to other entities. If A only knows to pass to B, then he can't be used to pass to anybody else. > In the other model, by taking business logic out of > the objects and into the manager the A, B, C, D become > more dependent on that specific manager, and less > hirable without him/her. Nope. No business logic gets transferred to the manager, except for higher level decisions, which belong there anyway. A doesn't get to decide whether he buys ingredients for bagels or cinnamon rolls, he just buys ingredients. If he is taught only to buy for bagels, he can't be used for cinnamon rolls. Some outside entity tells him what to do. He doesn't even need to know why. This is analagous to a shell script (in my Bourne shell analogy), or to a Cocoon script in the Cocoon analogy. Passing parameters to an application or a function does't mean you are sticking your fingers into its business. It means that you are telling it in general terms what it should operate on, not how it should operate. > > simplicity, > > and the ability to divide-and-conquer. > > For these two, indeed all of them, one can probably > argue either way. Let's agree to disagree. It is true that one can argue either way, but what is expected here is a *coherent* argument. If this is really just a matter of opinion, and the results don't matter, than you would surely have voted a +0 or a -0, instead of a -1. I'll admit I don't know everything, and perhaps you have some insight that I don't grasp. If so, I hope I am humble enought to learn. But I can't find anything to learn yet. WRT "let's agree to disagree", that might work well in a commercial environment where there is some higher authority that can resolve such issues. I think it is almost useless in Open Source. If you undo tomorrow or next year what I do today, we have both wasted a lot of time. So as time consuming and difficult as resolving stuff in this forum is sometimes, it is a lot more efficient than code thrashing. Assuming that we are both intelligent and reasonable, I can think of no good reason why we can't come to an agreement about design issues. I take no offense at the negative vote. But I want you to understand that I don't put proposals forth lightly. If there are aspects I don't see, please enlighten me. If my education is deficient, tell me, and I'll work on correcting it. Both are possible. However, I do take offense when proposals are disapproved with no coherent reason attached. That is either careless or disrespectful on your part. If you have a good reason for voting negatively, give it to us and defend it, but don't say "let's agree to disagree" and hide in the tall grass. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
