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:
> "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.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]