Originally posted by Jeroen Wenting:
No, MVC != OO.
MVC can be used in conjunction with OO, but it's not synonymous.
His ideas about OO are basically that EVERY object should be fully selfcontained and not either rely on anything else nor provide anything to anything else.
"Excuse me Smithers. I need to know the total bills that have been paid so far this quarter. No, don�t trouble yourself. If you�ll just lend me the key to your filing cabinet I�ll go through the records myself. I�m not that familiar with your filing system, but how complicated can it be? I�ll try not to make too much of a mess."
Smithers actually understands his filing system, so he can probably do the work faster than we can, and he�s much less likely to mess everything up. In seeking to do his job for him, we�re just making things worse. They�ll get a lot worse when he switches over to that new filing system next week. We�d be far better off with the stereotypical tyrant boss.
"SMITHERS! I need the total bills that have been paid since the beginning of the quarter. No, I�m not interested in the petty details of your filing system. I want that total, and I�ll expect it on my desk within the next half millisecond."
Consider the story of �The Paperboy and the Wallet,� from our friend David Bock. Suppose the paperboy comes to your door, demanding payment for the week. You turn around, and the paperboy pulls your wallet out of your back pocket, takes the two bucks, and puts the wallet back. As absurd as that sounds, many programs are written in this style, which leaves the code open to all sorts of problems (and explains why the paper boy is now driving a Lexus).
Instead of asking for the wallet, the paperboy should instead tell the customer to pay the $2.00. Code should work the same way�we want to tell objects what to do, not ask them for their state. Adhering to this notion of �Tell, Don�t Ask� is easier if you mentally categorize each of your functions and methods as either a command or a query, and document them as such in the source code (it helps if all commands are grouped together and all queries are grouped together). A routine acting as a command will likely change the object�s state and might also return some useful value as a convenience. A query just gives you information about the object�s state�and does not modify the object�s visible state. That is, queries should be free of side effects as seen from the outside world. Now, we might want to do some precalculation or caching behind the scenes as needed, but fetching the value of x should not change the value of y.
Command-query separation keeps code shy; the caller doesn�t know too much about how its command will be performed. That means we have reduced coupling by some measure, which is a good thing. Those implementation details are free to change with less chance of affecting the caller. Because the query methods are known to be side-effect free, we can use them freely in unit tests and call them from assertions or from the debugger.
Originally posted by Stan James:
MVC is largely about moving data from one place to another - from the view to the controller to the model to the view.
I don't think this is true. MVC is basically about separating business logic from input logic from presentation logic, mainly by using the Observer pattern.
Originally posted by Jeroen Wenting:
In Holub's vision, objects rely heavily on other objects to do things for them but never give those other objects the required data to do those things...
Say you have a persistence framework ...
But my designer, mr. Holub, has designed me without any means to tell that nice persistence framework what it needs to persist.
Being properly OO, I don't have a means to call the persistence framework myself and inject the data into it but being designed according to mr. Holubs principles I have no way of having the persistence framework ask me for my data either. ...
Of course the persistence framework when it reads data cannot tell me what data I should contain either because I also have no methods to insert data into me.
Now does the basic flaw in Holub's principle become clear?
All objects should be completely self-contained YET have minimal functionality and rely on other objects to do just about everything for them.
Originally posted by Warren Dew:
Ideally, generic programming would handle this. You write "persist" functionality once and apply it to any and all object classes that need to persist.
It will be interesting to see if Java's generic programming implementation actually supports this.
Originally posted by Frank Silbermann:
Even though _is_a_ relationships are more than hierarchical, most programming languages are limited to a single inheritance hierarchy.
in a business, our decision to have some people specialize in business and others in technology requires lots of nasty, boring meetings.
Just as the MVC design pattern requires a controller that knows internals of both the GUI and the business objects
Likewise, objects that contain display logic, business logic, and persistence logic tend to be too large and complex to maintain, and prevent us from making use of junior programmers who may have specialized in just one of those areas.