• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

MVC is not object oriented??

 
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I just read this article and a few others by Alan Holub, and I am very interested in what he has to say:
http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox_p.html
He suggests that getters and setters violate object-orientation, that all data should be private, that the MVC pattern is not object oriented, that objects must provide their own UI, and so on. Unfortunately, it's part 1 of a multipart article, so I can't find out where he's going with this!
Anybody care to supplement or dispute his statements? I'm very curious about what solutions he has for the problems he mentions. As someone trying to improve my encapsulation and refactoring skills, I am on the edge of my seat!
Oh wait, I found the rest of the series. Cool. I'll read it and find out what happens.....
Later!
e
 
Rancher
Posts: 1449
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmm...
Well, he says some things I agree with and other things I don't. One thing I really don't like is the tone of the article - very strident, almost like he doesn't believe what he is writing himself.
One thing that makes alarm bells go off for me is when someone starts saying something isn't OO. Many of the GoF design patterns aren't OO by the definition of this article. Are we going to through them out the window? I don't think so.
The objects must provide their own UI thing seems to be rather naive and only seems to exist because he defined a previous rule that sets and gets were evil. Based on my experience with the first OO system I did I thought in terms like this but the more experienced folks showed me that I needed to separate domain concepts from implementation concepts. If I have an domain object that has multiple views to it should I incorporate them all into one ever larger object or provide helper classes that separate things out? I know which one I'd pick.
As for MVC not being OO - by his definition it isn't. But I say it is. Who's right? Or maybe the real question is "Does it matter?" If you use MVC (or some other approach) and it makes your system more robust, flexible, and maintainable then you should use it even if it isn't as "OO" as something else that doesn't do these things for your system.
Well, that's my rant. I'm not sure if I will spend the time reading the other parts because I've heard a lot of this before and it wasn't convincing then and it isn't now.
What do other folks think?
John
 
eric moon
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, where did he get the "sets and gets" bit?? Why are they evil? I was hoping he would explain that, but all he said is that he gets in trouble when he doesn't keep his data private.
That said, it's hard for me to understand the need for getters and setters. I would certainly agree any data that doesn't need to be accessed outside a class should be private, but once you've decided that you need public access, why the additional abstraction of method calls??
I don't think I've ever gotten a satisfactory explanation of that one.
But I do like his tone. I love a good rant, even if it gets out of control somewhere along the line....
e
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The main advantage of method calls for sets and gets is that you decouple the underlying implementation from the external interface. It allows you to use the Decorator pattern transparently as well as several others. It allows you to implement referential integrity constraints in setters, and/or implement lazy construction in getters.
 
John Wetherbie
Rancher
Posts: 1449
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the "sets/gets are evil" is as bad as saying "you need a set/get method for every data member you have. You should have the interface your class needs and if this includes some sets and gets that is OK.
I mostly have used sets in association with getting an object into the state it needs to be in. You create an object with incomplete data and fill in as it arrives. Profiles of people/members of an organization are good examples of this.
Along the same lines - you'd use gets to access info about a member that you need. Maybe you want to send them an ecard on their birthday so you call getBirthday.
As for why you have access methods I think Frank explained it very well. I would add that the sets/gets allow the object to control how the underlying data in accessed and manipulated.
John
 
eric moon
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, I certainly wouldn't argue that gets and sets can be useful if you need to do more than just change the value of a variable. I guess I would ask: But if all you are doing is getting and setting a variable, why bother?
And I guess the answer is: so you can change the behavior later without changing the calls, right? Well, I guess that's what Frank means by decoupling the interface from the implementation... makes sense. And I suppose if you're really confident you'll never have to error check or lazily initialize a value, you could just make it a public variable. And I guess in the end, making that determination is more trouble than just writing the methods.
Anyway, I am going to read some more of this article, and see if I can figure out how he proposes to eliminate the need for these.... I frankly can't figure out how it's even possible. It seems like at least the need to construct an object in stages as data comes in is difficult (and pointless?) to avoid.
hmmm.
 
eric moon
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess I'm also always hoping somebody has come up with a "better way" to do something. That's why when somebody proposes an alternative to, say, MVC, I'm so curious.
But as I learn the intracacies of the language (and programming in general) I move more and more from thinking it seems needlessly complex to realizing that what's actually being done is much more complex than I realized, and the code is just reflecting that complexity....
On the other hand, I can think of plenty of examples of practices that have become industry standards, that I thought were a disaster from their inception... For instance, the new 1.4 JSpinner widget appears to model the Mac version, which I hated from day 1, rather than the much cooler behavior from my old Atari 1040 (which is used in virtually all music software on any platform to this day.)
So it goes.
 
High Plains Drifter
Posts: 7289
Netbeans IDE VI Editor
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's been a while since I read that article, and I wasn't entirely sure then that Holub had made his points.
If I read him correctly, Holub's argument on get/set was that it was glorified field access. With get and set, you still "bind" the calling method to the return type of the called method. Encapsulation protects the autonomy of a private implementation, but revealing that property directly through an accessor and mutator adds very little to the OO experience.
My take is that Holub was arguing against the immaturity of some patterns, regardless of their widespread use and/or effectiveness. He's imagining a far more abstracted plane, where the bulk of interaction among objects is true service. Instead of programmatically asking "how much fuel is left?" and getting back a number of gallons, for example, we should be asking "when do I need to refuel?" or something more service-oriented. We shouldn't be concerned with direct instrumentation, for lack of a better word.
Maybe I'm projecting on to that argument -- more recent readers, feel free to correct.
------------------
Michael Ernest, co-author of: The Complete Java 2 Certification Study Guide
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Exactly! Holub is right! Declaring instance variables private and providing public assessors for them is nothing more than a fancy way of revealing implementation details. One of the principle objectives of OO is data and implementation hiding. The fact that getFuelMileage() returns a double is revealing a crucial implementation detail. What happens if someone decides to change getFuelMileage() to return a float? The code is broke big-time is what; now the potentially huge ripple has to be followed through the application. The key to designing this way lies in defining a correct and robust Problem Statement constructed in the language of the problem domain. Holub has several articles on http://www.JavaWorld.com that go into great detail on problem statements, use cases, state transition diagrams, activity diagrams, etc. I must admit, I am a reformed getter/setter user, and I no longer pass data between objects. I know try to design my software around the problem statement and build my objects to be collections of capability that pass messages to other objects.

-Joey
 
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thought provoking article, but I find it slightly flawed...or at least, it leaves some very big questions unanswered.

I'm going to take up the third point (and the others indirectly): "Never ask an object for the information you need to do something; rather, ask the object that has the information to do the work for you."

In particular, he says objects should have their own UI. So as an extension of this, I could conclude further that:

  • Objects should be responsible for their own persistence
  • Objects should be responsible for translation into formats required by other (or legacy) systems: XML, for example.
  • Objects should be responsible for their own creation. (If they weren't how could they get initial data?


  • OK, so on the first point for example, you could counter by saying "well no, they just talk to a persistence object: persistMe(myFirstField, mySecondField, ...)." That's inconsistent with his UI principle though: I could say drawMe() as easily as persistMe().

    Have I drawn a fair conclusion from this article, or is there a flaw in my logic? If my conclusion is fair I'd just love to see Alan's "in the trenches" solutions.


    --Tim
    [ July 20, 2004: Message edited by: Tim West ]
     
    Joey Leary
    Greenhorn
    Posts: 7
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Tim,
     
    Joey Leary
    Greenhorn
    Posts: 7
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Tim,
    I have a lot of the same questions. However, I have a gut feeling that Allan really does know what he is talking about; search the web for all of the many successful projects he is responsible for. His credibility is not an issues with me, what is at issue is my ability to apply HIS OO philosophy to the typical problems that I solve with Java and OO solutions. To that end, I am going to delve into his RPN calculator article series and try and digest them. I need a real-world concrete example of his principles before I can start getting a warm-fuzzy about it.

    -Joey
     
    Ranch Hand
    Posts: 268
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Well, I think this guy has a particular, non-traditional view of OO that lends itself to the ideas he presents in the article.

    1. All data is private.

    Agreed. Any data that needs to be accessed, even from a subclass or within the class itself (!), should go through a getter. Yes, even in the class itself--otherwise, if a subclass overrides the getter, which could be a perfectly valid thing to do, it has to also override every other method in the base class that doesn't use the getter from within. Very hostile coding practice.

    2. get and set are evil.

    This one I'm not so crazy about. I think that the JavaBeans spec made a mistake by allowing setters to define their return values as JavaBeans properties. If I see a setX() method on a class, I think of that method just like any other method that performs an operation on the class--this one happens to alter the state of the class, but lots of other, non-setter methods do that too. Nothing special, and definitely no reason to go defining x as a "property" of the class just due to the presence of a setter.

    A getter, on the other hand, does define a property of the class. And not all internal data ought to have getters, Holub is right about that. But his attitude that every getter is just a fancy way of exposing implementation details is wrong. Getters are essential defining features of a class. Without them, an object's API can not be consistent or complete (I mean these terms in the mathematical sense). Let's say I write a class with a bunch of methods and I'm trying to define, for the purposes of documenting the method foo(), exactly what foo() does. It's not possible to do this unless I can say what foo() does with, or how it alters, publicly available properties of the object.

    Example: again consider a class that represents user credentials, a username and password. This class is immutable, once instantiated, these values cannot be changed. I write an operation that takes provided credentials and compares them to the values stored in this object. How do I define the behavior of this method if I can't say something like: "if arg1.equals(getUserName()) && arg2.equals(getPassword()), returns true". The userName and password properties must be available in the API somewhere. And it's not sufficient to speak about the values handed in during instantiation of the object--I might have a slightly different object where those values are simply unique IDs of the username and password which I then populate in the object from the DB. In this case, I couldn't speak about "the username and password associated with the ids handed in at construction time" either--the DB records might have changed in between construction time of the object and when the method is called, and to assume otherwise is to start documenting strange and convoluted dependencies into the API which don't actually exist.

    Before I move on, though, why do I think a setter shouldn't define a property, and instead just be treated as another method like any other? Well, consider a situation where two properties are not independently settable! (Properties are always independently gettable, so this only applies to sets.) Let's say I'm writing a class that represents a user credentials, a username and password. I want to write it such that it's mutable...that is, the data contained within a particular object can be set after instantiation. Let's also say that this class should never have a null username and non-null password and vice versa. Both null are fine--that's a valid state for the object, and both non-null are fine too.

    If I follow the standard JavaBeans model and provide getters and setters for both username and password, how do I prevent callers from setting one property to null and the other to a non-null state? It can't be done! In fact, if I want to allow the object to transition from a non-null state for both to a null state for both properties, it *must* for a short length of time exist in an invalid state. If the caller encounters some problem in between calling the first setter and the second, it could stay in that invalid state indefinitely.

    One way to approach this problem is to do away with both setters and replace them with a single setter, setUserNameAndPassword() that takes two arguments and sets both at the same time. This is a fine solution, except, according to the JavaBeans spec, now this object has *three* properties: username, password, and usernameAndPassword. Clearly this third one is not really a property, though...it's incorrectly defined this way because of the way the JavaBeans spec is written and for no other good OO reason.

    (Incidentally, a better solution than a single setter is to define an immutable class UserCredentials that contains the username and password. Then, create a second class MutableUserCredentials that aggregates a UserCredentials object and defines a setter, setUserCredentials(UserCredentials). This solves the problem elegantly, the JavaBeans spec notwithstanding.)

    3. Never ask for info from an object, ask it instead to do a job using the info it contains.

    This is pie-in-the-sky sometimes. Sometimes it makes objects too complicated, sometimes it conflicts with other important aspects of the design and architecture.

    Consider the Integer object. Sounds like Holub would argue this object ought to have add(), subtract(), divide(), sqrt(), pow(), etc, methods that takes another value (an Integer, perhaps? or a Double?) and performs the operation. But then...what should that method hand back? Consider add(), for instance. This method would have to hand back...an Integer object! And what would you do with that object if you couldn't get at the underlying primitive value?

    4. It must be possible to change the implementation of an object by modifying a single class.

    Here I part ways with Holub. I think of objects differently than he does, I guess...I have this idea of objects as a logical entity in an OO design, not a physical entity represented directly in the implementation. To me, for example, a component object model such as MVC is comprised of three physical objects, but I think of these three collaborating objects as a single logical object in the design. To me, the purpose of a component object model is to project a single object onto a set of orthogonal axes in order to break down its functionality into different components that can be individually maintained or replaced.

    Think of a meterstick in a plane, oriented at a 45 degree angle to the x-axis. Its length along the x-axis makes a projection less than a meter, and along the y-axis less than a meter. By breaking it down in this way, we can deal with these two components of the same meter stick independently. Same thing with component object models, except we're taking a single object and projecting it onto a set of three axes: the model-axis, the view-axis, and the controller-axis. By using MVC, we've made the view an independent concern for each logical object, meaning we only need to alter things in the view dimension if we wish to change the view without concerning ourselves with other code in the object. So, if a change to such an object were to impact both the model and the controller, for example, I don't see a problem with that.

    5. All objects must provide their own UI.

    The example provided in the article sounds pretty good...the only thing I would point out is that it totally avoids the important subject of dependencies. Rather than code a TextField object into the UI to allow the user to enter a name, Holub says it's better to pass the UI (a Graphics object or a JPanel or something) to the object responsible for representing the name, and have it display a TextField (or whatever) in the area of the UI in which its instructed to do so. Would such an object also be responsible for taking a handle into the DB and persisting the value entered? If so, this means that this name object must be handed vertically throughout the entire system, from persistence layer to presentation layer, and this is rarely a good idea in an n-tiered system. For one, it creates an untenable deployment situation where, if these tiers are being deployed on different systems, there must be a shared common jar containing classes like this name object deployed everywhere. Creating such a dependency of all tiers on common classes could get very, very tricky in the real world.

    Overall I think he makes a lot of good points and gives us some things to think about. I think it's important to constantly challenge conventional wisdom...like a scientific theory, conventional wisdom must be tested if it's going to improve. I'm just not sure the total package of what he presents answers more questions than it raises...though I have to admit I'll be spending some time thinking through these issues a bit more.

    sev
    [ July 21, 2004: Message edited by: sever oon ]
     
    Ranch Hand
    Posts: 5093
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Mr. Holub is an old C person who never got used to the Java way of doing things and continues to try turning Java into C++.

    I've read several of his publications and with every one I loose more of my respect for his opinions.

    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.
    So an object gets its own GUI for input and output, its own validation and data retrieval and storage code, etc. etc.
    Effectively each and every object is an entire application with everything that comes with it, a setback to the old days of massive C sources and copy/paste programming.

    No, MVC != OO.
    MVC can be used in conjunction with OO, but it's not synonymous.
    Same with most pattterns and pattern combinations.
     
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Jeroen Wenting:
    No, MVC != OO.
    MVC can be used in conjunction with OO, but it's not synonymous.



    It's not synonymous with OO, but it makes heavy use of it. For example, the Observer pattern is basic OO.
     
    (instanceof Sidekick)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator


    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.


    I think that's the opposite of his idea. He says you should depend heavily on other objects to do things for you, but not to give you data so you can do things yourself. If you focus on designing objects only by behavior and responsibility you wind up with very few getters & setters. It's a case of setting impossibly high goals but it's good to think this way.

    MVC is largely about moving data from one place to another - from the view to the controller to the model to the view. It's not as pure as having objects do all their own work but it is a necessary compromise for some architectures and a useful compromise in many others. I find his ideas about self-displaying objects a nice fantasy but completely impractical. I'd rather accept the compromise.

    Here are a couple things (that have been on the ranch before, maybe in this thread!) that help understand Holub's basic point of view ...

    "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."


    and another ...


    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.



    More here: http://www.surfscranton.com/architecture/LawOfDemeter.htm
    and http://www.surfscranton.com/architecture/KnightsPrinciples.htm
    [ July 21, 2004: Message edited by: Stan James ]
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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.

    It's not hard to imagine doing this while still holding to the "Hollywood Principle". For example, a view could be implemented along the lines of



    That is, you could probably implement MVC without using setters/getters at all. With other words, "all objects must provide their own UI" is far from being an OO principle - quite to the contrary, it violates several important OO principles, such as the Single Responsibility Principle and the Dependency Inversion Principle.

    But would it be worth it? We need to remember that using OO techniques is not an goal in itself. We are using OO to better manage dependencies in our source code, so that it gets easier and less costly to maintain and extend.

    So, what's the problem with getters and setters? The problem is when we use them to tamper with the internals of an object. For example, in



    this code actually belongs into the Color class itself, exposed by an adjustBrightness method or something, for very pragmatic reasons: for other implementations of Color (for example using a YCM palette) the above implementation might compile, but not be optimal or even correct.

    Is the same problem present with canonical MVC? I don't think so...
     
    Ranch Hand
    Posts: 1419
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Object orientation must be compromised when dealing with an impedence mismatch. This happens when our program must deal with components that either are not object oriented, or which are object oriented at a different level of abstraction.

    For example, relational databases simply are not object oriented. To use a RDBMS to persist objects, we simply must violate our objects' encapsulation. (That's why ugly, repetitive, boring data access code tends to dominate most data processing applications.) This is true even if you use objects to implement the relational database commands, as is done by JDBC -- the object orientation is at a different level of abstraction.

    Nor is HTML object oriented, so we get yet another impedence mismatch when trying to build the user interface of web applications. I would say that this impedence mismatch is even worse than the RDBMS impedence mismatch (which is why it seems that every month someone is announcing a new web API to satisfy heretofore unresolved needs).

    Finally, program organization for object orientation that makes code easy to read and understand sometimes must be compromised in favor of organizations motivated by other concerns (such as the separation of stable business logic from logic that is likely to change). Much of the MVC pattern is motivated by this.

    I think that "interface-oriented" would be a more accurate description for languages currently described as "object-oriented." To benefit from compile-time error-checking and code optimization, these languages may be designed with polymorphic interface-oriented (not object-oriented) type systems.

    The expressiveness of an interface-oriented language allows us to write object oriented programs. Or, we can use the language's expressiveness to satisfy other concerns (such as the localization of expected future program changes). Sometimes we can do both -- but not always.
     
    Stan James
    (instanceof Sidekick)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator


    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.



    Good catch. That's the objective and purpose fer sure. The mechanics can wind up having a lot to do with data, especially when people call Struts or some other front controller MVC. I'm using a vendor framework where the front servlet calls a command that gets data from the model, puts it on a session-based cache, transfers to a JSP that pulls it back out. Business logic, presentation and control are nicely separated but the glue is messy. That's what made me say "necessary compromise".
     
    Jeroen Wenting
    Ranch Hand
    Posts: 5093
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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 to write to a database (or whereever, I as an object containing something to be persisted don't care).
    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.
    Catch 22, I can't tell the persistence framework what to persist in any way whatsoever.

    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.
     
    Frank Silbermann
    Ranch Hand
    Posts: 1419
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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.



    I think there's probably an analogy between program organization and business organization:

    Even though _is_a_ relationships are more than hierarchical, most programming languages are limited to a single inheritance hierarchy. Likewise, even though business communication is a network, organization charts are almost always tree-shaped.

    In a program, our desire to have separate tiers for presentation logic and persistence logic compromises the ability of objects to keep their implementation details to themselves. Likewise, 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, the division between businessmen and programmers creates a need for systems analysts who understand both the business objectives and the technological options and trade-offs.

    Yes, things would be simpler if objects could simply persist themselves or display themselves on command, without having to expose their internal implementations to others. Likewise, it would be easier to run a business if every businessman could implement his own data processing. But most people aren't smart enough to maintain expertise in both the ongoing business and in changing technology. 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.

    In programming, as in life, maximizing cohesion and minimizing tight coupling in one dimension of the problem compomises the cohesion and loose coupling in another dimension of the problem. A good designer makes good trade-offs; a bad designer makes unnecessary compromises. The compromises Golub highlighted seem to be necessary compromises.
     
    Stan James
    (instanceof Sidekick)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    At the object-relational boundary some non-OO compromise is required. Getters and setters are necessary in some architectures. That doesn't mean they are good OO. Holub's points about the potential problems are still good. The advice to avoid get & set and to stop and think about alternatives is still good. The necessity of using get & set in one compromise situation doesn't make them ok everywhere.
     
    blacksmith
    Posts: 1332
    2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Frank Silbermann:

    Yes, things would be simpler if objects could simply persist themselves or display themselves on command, without having to expose their internal implementations to others.

    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.
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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.



    Isn't that what persistence frameworks like Hibernate are already doing???


    It will be interesting to see if Java's generic programming implementation actually supports this.



    You are speaking about generics coming with Tiger? I don't see how that would connect to the above...
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Frank Silbermann:
    Even though _is_a_ relationships are more than hierarchical, most programming languages are limited to a single inheritance hierarchy.



    Attention: looking for "is a" relationships is only a *heuristic* for implementing inheritance relationships - they are far from being the same!

    in a business, our decision to have some people specialize in business and others in technology requires lots of nasty, boring meetings.



    Well, I am far from convinced that this really is a requirement. I'd rather think that a well lead business would lead to just enough interesting and informative meetings... :roll:

    Just as the MVC design pattern requires a controller that knows internals of both the GUI and the business objects



    I don't really see that Controller is required to know about those internals.

    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.



    That's actually not the most important problem - a team consisting only of expert programmers still would benefit from a Model-View separation. Reasons for doing so are: not having to re-test the model when you change the view, and being able to reuse the model with different views, for example.
     
    Warren Dew
    blacksmith
    Posts: 1332
    2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Ilja Preuss:

    Isn't that what persistence frameworks like Hibernate are already doing???

    I was just using persistence as an example. Hibernate does it for persistence, yes. With fully implemented generic programming, you could easily do the same thing for other class aspects without the overhead of writing a framework.
     
    WHAT is your favorite color? Blue, no yellow, ahhhhhhh! Tiny ad:
    Smokeless wood heat with a rocket mass heater
    https://woodheat.net
    reply
      Bookmark Topic Watch Topic
    • New Topic