Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Books Media Programming Book Reviews Technology

Holub on Patterns 211

Posted by timothy from the look-pretty dept.
James Edward Gray II writes "Apress sent me a copy of Holub on Patterns for review, and for that I'm extremely grateful, because this is a gem of a book I would not have liked to miss. Odds are, most object-oriented programmers will feel the same, so allow me to share the highlights." Read on for the rest of Gray's review.
Holub on Patterns: Learning Design Patterns by Looking at Code
author Allen Holub
pages 414
publisher Apress
rating 9
reviewer James Edward Gray II
ISBN 159059388X
summary Design Patterns taught through Real World Programs.

If I can level any complaint against this book, it's probably that the title doesn't properly convey the goodness locked within. Holub on Patterns is short for Allen Holub on Design Patterns. Allen Holub is a long time expert on Design and Design Patterns, so he's the man you want to learn it from. Still, if I could name this book, it would be Object Oriented Design Voodoo. (Note: This is probably why I don't work for Apress or any other publisher.)

The book's subtitle is "Learning Design Patterns by Looking at Code." That probably conveys the work's focus a little better and it also gives away one of the book's best features: sensational examples. (These examples are in Java, another area where Holub is a well-known authority, but the concepts taught apply to Object Oriented Programming in any language.)

Titles aside, this book really is the best work I've read on design patterns. If you don't already know, design patterns are the recurring patterns of object-oriented software implementations. Luckily, you don't have to know anything about them to read this book. The author covers many patterns in rich detail from the beginning. Even if you do know your design patterns well, I'll wager Holub still has a trick or two to impress you with.

Holub discusses patterns in their ideal pure form, but much more importantly he shows them as they occur "in the wild," with multiple variations. He covers the downside of each pattern, weights the trade-offs of using them, and even gives a handful of cases where he felt they were impractical. He does all this right in the middle of complex real-world examples so you can see each point he's making. That's actual programming, folks. The good, the bad and the choices we programmers make are well presented, and that's rare in a programming text.

The book opens with two chapters that more or less cover why we need design patterns at all. Did you know getters/setters are bad? Did you know that subclassing is dangerous? If you said No to either question, you need this book and these two chapters in particular will get you up to speed on good OO practices. This section of the book is mostly theory, light on examples.

The next two chapters (covering over 250 pages) make up the heart of the book. Holub examines two examples in exhaustive detail. The first is his implementation of The Game of Life. You've probably implemented that on your TI calculator, but Holub sure didn't. He admits that his implementation is "Toy Code," but it's a robust example that involves eleven design patterns. The second example is production code, a mini database complete with SQL interpreter. This code is also swimming in pattern usage, and Holub gives you the guided tour.

I've already said these examples are great, but that claim begs some elaboration. First, we're talking about hundreds of lines of code in many of these listings. These aren't the usual contrived junk. What's more, one class may be participating in multiple patterns. Making any sense of these examples would be almost impossible if the author wasn't flawless in explaining the key points and always dropping hints about what you need to notice. This isn't light reading. It's work, but the rewards are there and it'll pay off if you really spend the effort to understand how the code works.

Finally, the book closes with an appendix that gives more typical recipe-card style listings of all the design patterns discussed throughout the text. This is a nice reference after you've finished the tricky stuff. If you're new to design patterns, you might start here, before the book throws you into the lion's den with its massive examples.

Just in case I haven't sold you on this title yet, I better mention the gorgeous hard back binding. Brilliant and sexy. How can you beat that?

Holub on Patterns is a very approachable way to learn a lot about design patterns. If you already know how much patterns can improve your object-oriented programming, you'll really enjoy Holub's presentation of the topic. If you don't yet grasp Design Patterns or haven't enjoyed other works on the subject, you'll just have to trust me: You want this book.

You can purchase Holub on Patterns: Learning Design Patterns by Looking at Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Holub on Patterns More

Holub on Patterns

Comments Filter:

  • Witch doctors (Score:3, Funny)

    by MikeMacK ( 788889 ) on Tuesday November 16, 2004 @05:17PM (#10835415)
    Still, if I could name this book, it would be Object Oriented Design Voodoo.

    Great, now we're getting book reviews by witch doctors!

    • Finally, the book closes with an appendix that gives more typical recipe-card style listings of all the design patterns discussed throughout the text.

      What? Is that supposed to be some sort of witch's brew?

  • Official site (Score:5, Informative)

    by the_mighty_$ ( 726261 ) on Tuesday November 16, 2004 @05:17PM (#10835418)
    The official site is located here [holub.com].

  • Getters/setters bad? (Score:5, Interesting)

    by d_jedi ( 773213 ) on Tuesday November 16, 2004 @05:26PM (#10835546)
    The book opens with two chapters that more or less cover why we need design patterns at all. Did you know getters/setters are bad? Did you know that subclassing is dangerous? If you said No to either question, you need this book and these two chapters in particular will get you up to speed on good OO practices.

    Can someone explain why accessor and mutator methods (I assume this is what he means by "getters/setters") are bad?

    • Re:Getters/setters bad? (Score:2, Insightful)

      by Anonymous Coward
      Under the hood, actuators and mutators are method calls (at least in C#), but if the property is simple enough, there's no reason it can't be treated like simple field access.

      Properties allow you to wrap your fields with business logic and validation, so I don't see what's so bad about that.

      • Re:Getters/setters bad? (Score:3, Interesting)

        by UWC ( 664779 )
        I was recently reading up on .net stuff and came across a description of properties. My previous exposure to design patterns was pretty much exclusively C++ based. I agree that addressing simple actuator and mutator functionality would do well to be treated at a lower level than method calls, but I had never come across the concept of properties like that. The examples in what I was reading used C# but apparently properties are also usable in the other .net languages. Is such an implementation fairly new, o

    • Re:Getters/setters bad? (Score:5, Insightful)

      by Misch ( 158807 ) on Tuesday November 16, 2004 @05:35PM (#10835660) Homepage
      Can someone explain why accessor and mutator methods (I assume this is what he means by "getters/setters") are bad?

      My guess is that in some instances, publically accessible getter/setter methods can be construed to be "exposing the underlying implementation" of a class. Of course, that just means you need to judiciously use getter and setter methods.

      That's my guess at least. I suppose I should read the book.
      • Can someone explain why accessor and mutator methods (I assume this is what he means by "getters/setters") are bad?

        My guess is that in some instances, publically accessible getter/setter methods can be construed to be "exposing the underlying implementation" of a class. Of course, that just means you need to judiciously use getter and setter methods.

         Hmm, so don't make them all public? I agree that classes should only let you get and set things that are meaningful outside the class by things like V

    • Re:Getters/setters bad? (Score:4, Informative)

      by SpaceTux ( 453664 ) on Tuesday November 16, 2004 @05:36PM (#10835676)
      Holub explains, check the articles on Javaworld (you can find links at Holub.com)

      It took some time before Holub convinced me with his articles on Javaworld. But when I was convinced, I looked forward to the release of his book, which I have bought immediately.

      BTW. Accessor/Mutator methods aren't bad always though, for example, when you use them to access a non-object-oriented part of your software system (e.g. file system / database / GUI widgets)..

    • Re:Getters/setters bad? (Score:4, Informative)

      by homebrewmike ( 709361 ) on Tuesday November 16, 2004 @05:37PM (#10835697)
      Here's a good explanation: http://www.javaworld.com/javaworld/jw-09-2003/jw-0 905-toolbox.html
      • That link again, without the extraneous space: http://www.javaworld.com/javaworld/jw-09-2003/jw-0 905-toolbox.html [javaworld.com].

      • More-OO-than-thou religious fanatics (Score:4, Insightful)

        by Latent Heat ( 558884 ) on Wednesday November 17, 2004 @11:22AM (#10842142)
        First it was this Law of Demeter business where you weren't supposed to invoke a method of an object you retrieved from another object and you were to either implement gobs of forwarding methods or implement "visitor" objects to do the forwarding or some such thing.

        Then there was the "inheritance is bad" deal where everything is to be done with composition and you have to write gobs of forwarding methods between the object and the object it contains.

        Now there is this "Get/Set is harmful" -- no, "Evil" I say because this is a matter of religion. So what are you supposed to do when you need to get some representation of state out of an object -- to display it? Can you do a getStateValue()? Oh, no! You have to hand that object an AWT graphics context object and have the object render itself. So much for reusing that object outside of Java.

        Or in another Golub article referenced on this topic, you are not supposed to have set functions to initialize an object to a required state -- you are supposed to pass your object a "Visitor" or "Strategy" object that supplies the state -- through what? An interface with a whole raft of get functions?

        Suppose the approach was, "Do you have a whole lot of get methods on an object? Why are they there? Is it because you need to retrieve the state of an object to print it out? Have you considered giving your object a Print() method and getting rid of all of the get methods? Are you concerned that your object is now hard-wired into a particular print driver? Have you considered implementing an abstract print interface and implementing void Print(IPrintInterface my_printer) as the Print method?"

        But no. The approach is that get/set is "evil" or "smells bad" or some such thing. An object with get/set is a kind of shame and you have to go to extreme contortions in your code, spinning off bunches of classes you never needed before to avoid the embarrassment of having get/set.

        • So what are you supposed to do when you need to get some representation of state out of an object -- to display it? Can you do a getStateValue()? Oh, no! You have to hand that object an AWT graphics context object and have the object render itself.

          When I first read that, I assumed you were joking, and had just made that up as an absurd example to exaggerate the author's point. Then I read TFA, and realised that Holub himself advocated exactly that. Talk about getting your priorities completely wrong!

          G

    • Re:Getters/setters bad? (Score:5, Informative)

      by FerretFrottage ( 714136 ) on Tuesday November 16, 2004 @05:37PM (#10835698)
      Look here [holub.com]

      • Re:Getters/setters bad? (Score:4, Insightful)

        by emiddlec ( 673376 ) on Tuesday November 16, 2004 @05:57PM (#10835930)
        The article Why getter and setter methods are evil [javaworld.com] (from above) includes the following:

        1. A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details.

        Apparently the argument against getter / setter functions goes..

        1. OO systems should not expose implementation
        2. Getter and setter functions mostly expose access to implementation details
        3. Therefore, OO systems should avoid getter and setter functions

        While the logic is sound, I think that item #2 is debatable.. If you design an object and mindlessly add get/set functions for every piece of private data in the object, then you're probably guilty of exposing the implementation. But if you design the object's public interface first, and decide on the private data afterwards, I would guess that you're probably in the clear to have used get/set functions "correctly." IMO it's not the functions themselves that are the problem, but rather the adherence to correct design principles.

        • >A fundamental precept of OO systems is that an >object should not expose any of its implementation >details.

          That's why we don't call hash tables HashTables, we call them "unorderedBagsIndexedByArbitraryKeysWithConstantTi me Acces", because that describes the PROPERTIES of the class rather than the IMPLEMENTATION. Oh, wait...

          • Re:Getters/setters bad? (Score:4, Insightful)

            by TheSunborn ( 68004 ) <mtilstedNO@SPAMgmail.com> on Tuesday November 16, 2004 @07:35PM (#10836939)
            (Talking about the way java does things)

            But you don't code to the interface(api) of a HashTable. You code to the Map interface, which is described as: "
            An object that maps keys to values. A map cannot contain duplicate keys; each key can map to at most one value."

            And you don't(Should not) give a HashTable to a method. Give it a Map insted. The only place in your code where the exact type matters, is where you create the object.

            That most people call them hashtables insted of associative array(or maps) are because they mix implementation and interface.

            I once did implement a Map using a linked list. Not effective, but a nice way to show the difference between interface and implementation.

          • I usually say something like this:

            Map someMapINeed = new HashMap();

            so that the implementation chosen (HashMap, the Java 1.2+ expression of the general idea of a hash table) is present only at that one spot, the rest of the code doesn't care about the Hashness of it, it just uses it as a Map.

            It is a common "smell" in Java code, to refer to something specific (HashMap) in a parameter list (most commonly) when you only need the generic.

        • Re:Getters/setters bad? (Score:4, Insightful)

          by killjoe ( 766577 ) on Tuesday November 16, 2004 @07:47PM (#10837075)
          It looks like we have come full circle. Nowadays it's fashionable to create value objects which are pretty much like the hashes and recordsets of the old days. Make value objects with public attributes, make action objects that take the value objects and maipulate them.

          As I said just like the old days.
          • I don't quite see where hashes and recordsets help the compiler to catch your typos. As with both hashes and recordsets, you rely (for the most part) on some String key, which is a bit of a nuisance when a typo etc. happens. Oh yes, you can put the keys in a Constants class or somesuch, but this becomes a pain rather fast.

            Not that I'd see this as the most gigantic leap ever done in programming, but it adds to a general repertoire of best practices, which, as a whole, is imho a lot more than just "coming ba
        • If you design an object and mindlessly add get/set functions for every piece of private data in the object, then you're probably guilty of exposing the implementation. But if you design the object's public interface first, and decide on the private data afterwards, I would guess that you're probably in the clear to have used get/set functions "correctly." IMO it's not the functions themselves that are the problem, but rather the adherence to correct design principles.

          I agree entirely. Too much of anythi

    • Re:Getters/setters bad? (Score:3, Insightful)

      by fizban ( 58094 )
      In the OO world, objects come in two basic flavors: data objects and interface objects.

      Data objects are just groupings of data. The member variables should be public and accessible to it's users.

      Interface objects, however, encapsulate their data. They don't require the user to know about their internal data members and only provide methods members that the outside world can use to perform actions with that object.

      In the first case, you don't need getters and setters because the members are already public

      • Re:Getters/setters bad? (Score:5, Insightful)

        by philci52 ( 673066 ) on Tuesday November 16, 2004 @06:40PM (#10836418)
        In the first case, you don't need getters and setters because the members are already public.

        Having public members is generally a bad idea and gives me nightmares of old C structures. Here is the reason that you should use set/get methods:

        1. Debugging - Try and trace a variable every time it is set when the variables are public. Wonder why you can't figure where it is going wrong? Adding 100 break points? Using set/get here can save hours of debugging.

        2. No loss of Speed - most compilers will optomize your set/get functions if they are inline, so there is no performance penalty (atleast for c++).

        3. Maintainance - Suppose that when data member A is updated, now a count needs to be kept. Using a setter function allows you to change code in one 1 place. Also, suppose a variable type changes from an int to a double. You can still keep around the integer setters/getters for older classes and use new accessor for the new methods for objects that need it.

        From the article, its not that setters/getters are bad themselves, but that overuse of them is bad. Here is the key quote: Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.
        • Item 41 in the book "C++ Coding Standards" is:
          Make data members private, except in behaviorless aggregates (C-style structs).

          We've gone round and round on this where I work but the long and the short it is that Sutter and Alexandrescu are correct. Large collections of setters/getters are generally signs of a bad design. If you have a struct that maybe has some basic functionality that isn't germain to the purpose of the class then simplify it and put it in structs. If it does something then design it so

      • Re:Getters/setters bad? (Score:3, Insightful)

        by fupeg ( 653970 )
        Your "data object" is not an object at all. Read the most basic definition [wikipedia.org]. Your "data object" is exactly what Holub is talking about as being "evil." Your "data object" is a struct, and you are being procedural, not object oriented. The whole point of OO is to combine these two things into an object. Accessors violate this paradigm. In a good OO system, other objects never ask for information about other objects, they simply ask the other object to perform tasks.
        • "In a good OO system, other objects never ask for information about other objects, they simply ask the other object to perform tasks"

          At some stage you will have to get some data from an object. Very simple example, lets say you are writing up a shopping cart. Add item objects to the cart. How will this cart keep track of the subtotal without querying the item objects as to their price?
          OK, we have:
          cart.add(item);
          At some stage the cart object will have to call: item.getPrice();
          Very simple example, but I a
          • If other objects should never ask for information about other objects (whether it be from the other objects or some other property fairy), then why does OO so depend on RTTI (a particular kind of object property fairy) and other methods of type discovery to work?

            Hmm...
          • Sometimes data flow is necessary such as in the example you give. However, that does not mean that the only way to solve such a problem is a procedural solution. There are object oriented solutions to such a problem as well.
            The key concept is encapsulation. If you expose your attribute (price) to the whole world, then an unlimited number of clients can couple themselves to this, creating brittle code. So use a Builder pattern [c2.com]. Define an interface for exporting information about your Item object. For som

            • The key concept is encapsulation. If you expose your attribute (price) to the whole world, then an unlimited number of clients can couple themselves to this, creating brittle code.

              Do you often write a shopping application, and then find that the items for sale no longer have a price? Ensuring that the Price type is user-defined (if only as a synonym for double at first) should be plenty of future-proofing for now.

              So use a Builder pattern . Define an interface for exporting information about your Item

      • Re:Getters/setters bad? (Score:4, Interesting)

        by Cyberfox ( 17743 ) on Tuesday November 16, 2004 @06:55PM (#10836559) Homepage
        Greetings,
        Data objects are just groupings of data. The member variables should be public and accessible to it's users.

        This is the only thing I disagree with in that. I believe that a get/set interface to data objects is in fact the only right place for get/setters.

        Why? Because you might want to abstract that data object into something more intelligent in a later refactoring, and then you have the burden of replacing every variable reference in everything that touches that class. Nasty, nasty stuff, and it's better to design that nastiness out in the first place.

        I believe in no public member variables, as a general rule (breakable, of course, on occasion, but terribly rarely), as it causes too tight a binding between classes and the value objects that are passed around (called 'tying' by some). This may put me at odds with Holub (I haven't read this book yet), but it wouldn't be the first time.

        Holub is an EXCEPTIONALLY good introductory author, very easy to read, and clearly brings you to the point he's trying to make. However, I recall coming back to his C books after many years as a professional developer, re-reading them out of curiousity, and realizing that he was teaching a few principles that were questionable at best, and ignored at-the-time best practices. Now it's very possible that he would also think they are questionable these days, but putting them in a book lends them an air of authority through time.

        I'll probably pick up the book, as more examples of good pattern use are always valuable, but as an engineer who has developed countless classes where 'value objects' become more intelligent, I strongly recommend against direct member variable access.

        -- Morgan Schweers, CyberFOX!

      • Re:Getters/setters bad? (Score:3, Insightful)

        by marms ( 134726 )
        An obvious reason not to use "public" members in Data Objects is if the member must be validated to prevent illegal values from being assigned. Or if changing one member will automatically cause other members to be changed. Or if the internal encoding of an object differs from the external representation. Or if sychronization or transactions are needed. Or to prevent access/mod by certain classes or users or under other circumstances. Need I go on? Yes, there are times when using "public" members is fine (t
      • Greetings,
        A telling quote from Holub's article on his site about getters/setters...

        We do know how we will use the classes, so you don't have to waste time building unnecessary flexibility.

        His article actually explicitly is against the public accessible groupings of data, preferring instead what is (to me) equally distasteful, which is having the 'data objects' know everything that could be done with them, and contain the functionality to do it all. This is fine if you never need flexibility in your dat

    • Re:Getters/setters bad? (Score:4, Insightful)

      by Greyfox ( 87712 ) on Tuesday November 16, 2004 @05:40PM (#10835735) Homepage Journal
      Object Oriented programming is all about hiding data. You expose just the data you need through very specific interfaces. If you have an object that has getters and setters for every data element in the object then you're still exposing the internal workings of that object and should reconsider your design.

      Of course, being a programmer also means knowing when to break the rules, and there will be some times when you can't avoid using them. IIRC, a lot of Java stuff requires them. I prefer not to use Java if I can avoid it.

      • IIRC, a lot of Java stuff requires them. I prefer not to use Java if I can avoid it

        Actually, it's "only" many (most) Java data-binding libraries/frameworks that require them; and even then, Objects in question are mere data containers (data transfer/access objects etc). So avoiding the whole language is bit silly, if the main reason is avoiding having to create get/set methods. Java as a programming language has no dependency on such methods.

        However, I also strongly dislike the "automatic" (ie. add ge

      • IIRC, a lot of Java stuff requires them.

        Hmmm, I must be new to Java programming then. Some languages may use properties instead, but whats the difference? Anyway, people tend to forget that Java is a language that has little rules, and is thus easy to learn and parse (use Eclipse, and you know what I'm talking about). Adding properties etc. etc. would break that design decission. Just don't use get/set sparingly (think about your interface) and you're fine. Most java IDE's out there can create getters and
        • Check out the specs for anything with "bean" in the name, and also java data objects. Pretty much anywhere you get into pushing data around, the spec will call for getters and setters.

          Having the IDE create them automatically is going the wrong way, encouraging bad programming habits and illustrating the IDE designer's failure to comprehend the nature of object oriented design.

      • OO has nothing to do with data hiding, it has everything to do with data protection: you want to know at every point in your code that the data in the object is in a meaningful state. This meaningful state is called the invariant of the class. I you cannot state an invariant for a collection of data, you either think harder or make the data publically available. Data hiding is not an end, it is a means of making sure that the invariant is maintained. If there's no invariant, there is no use for data hiding.
    • Two things spring to mind (without having read the book)

      1. I see a lot of code where *every* attribute is assigned a get/set method as a matter of course (someone probably hit the "select all" button when generating them in the IDE of choice). Without additional "defensive code" inside this is tantamount to simply making everything public (shiver). Only expose what you have to.

      2. An object composed purely of getter/setters really is nothing more than a data container. Good OO practice suggests that obj

    • Re:Getters/setters bad? (Score:2, Insightful)

      by Anonymous Coward
      Nice how everyone who replied thus far failed to mention the Uniform Access Principle. Google it. That's why mutators/accessors are generally a good idea.

      Best practices may be generally preferable to other practices, but won't apply in every situation. Be pragmatic people!

      And to those of you talking about 'data classes', you're betraying a C-like heritage where data resided in structs or unions because of language limitations. Please keep your OO misconceptions to yourselves!
    • I'm assuming they don't like it because it promotes "intimate" knowledge of the object.

      If you have a rule object whose job is to compute the scoring moves of a game, you shouldn't be asking it "what is the score of a headshot?" You should be telling it "I made a headshot" and let it worry about the score.

      If you start having other parts of the app getting that intimate knowledge, your app "crusts over". Now, if you change the scoring rules regarding headshots, not only do you have a rules engine to upd

    • Let's take an example in java:

      class Foo {
      public int getValue() { return m_value; }
      public void setValue(int v) { m_value = v; }
      private int m_value = 0;
      }

      and now this:

      class Foo {
      public int m_value = 0;
      }

      There is absolutely no difference in functionality here, so there is no need for getter/setter for something which does not get any benefit of scope.

      If you has something like this, then it makes sense to have a getter/setter:

      class Foo {
      public int getValue() { return 2 * m_value + 10; }
      pub

      • Well, there is no difference in functionality in this version, but when I later want to change it so that m_value is actually MValueService.getWidgetCount() in the simpler version I can't unless I control every single class that uses this class and accesses the variable I now want to hide.

        Plan for the future, and don't expose instance variables except in private inner classes and other very limited use containers.
      • Ok, this post completely misses the point. You don't provide getters/setters to insulate the client from functionality - you provide getters/setters to insulate the client from change.

        Change is inevitable. You've got to plan for it. So, 6 months down the road when you realize that you need to change this requirement and add some functionality you won't be able to because you've directly exposed the member without hiding it behind a getter/setter.
      • I don't think that's what he's talking about.

        He's saying that if you need to access data in an object, you have probably failed to properly design your objects. He's saying that you should minimize any data access and any data sharing between objects. If some object has information that you need in order to do something, tell the object to do it for you.

        Thus, if you feel the need for getters and setters, you've made a mistake elsewhere.

        Whether or not that's always good advice I'll leave to someone who is
    • I think the classic explanation is more of you perform actions on objects not assign values. Therefore you would not be assigning a '5' to a value you would be performing an action like 'fill tank' on a car object with 5 (meaning litres).

      Calling the routine literally get and set shows no 'object orientation'. Therefore you consider them bad because of stylistic ideals which is to think in actions rather than programatically.

      Like all rules (like speeding when driving) it takes experience to know when to
    • Ok, to summarize his point. If you are making a "thing" then the operations on that thing should be contained inside that thing. So if you make these little routines that do nothing more than let you peek into "thing" to see "the real thing" inside, your "thing" isn't your friend.

      As a peice of mental oragmi (and to fold my own self in here, instead of _just_ trying to paraphrase this guy).

      There is nothing wrong (IMHO) to exposing parts of your thing via accessors and setters AS LONG AS you think of thes
    • Well, Holub explains this at length in his article [javaworld.com]. Let me rephrase and summarize what I understand of what he says.

      I think his chain of reasoning (and mine :) is somewhat like this (anyone can personally agree or disagree with any of these, of course):

      - Software design is a separate activity, different from coding.
      - Good software designs must stick to their underlying paradigm (OO in this case) as much as possible, to reap as much of its benefits as possible.
      - Encapsulation is a quality that provides mos
    • Can someone explain why accessor and mutator methods (I assume this is what he means by "getters/setters") are bad?

      It's a bad design that promotes bad usage.

      Consider the extreme case, where all attributes (sub-objects) of the main object are accessable and mutable: in this case, there's little real difference between the object in question and a C struct.

      You've gained nothing over a C struct other than the ability to call it an object.

      Except to essentially log any calls to getter/setters -- but you ca
    • Check a principle called the 'Law Of Demeter'. I have a paper about it on my website called, "the Paperboy, the Wallet, and the law of Demeter" [javaguy.org]. This will answer your question. In short, it is better to provide the common functions developers will need of your objects, rather than just expose the parts and let them manipulate them manually. Any piece of advice can be followed pragmatically or dogmatically though... Your mileage may vary.

  • Applicability to other forms of development (Score:4, Interesting)

    by nanter ( 613346 ) on Tuesday November 16, 2004 @05:30PM (#10835599)
    Object oriented patterns are great, and there have been numerous books written that have covered some of the most valuable OO patterns in use. I've recently started work in service oriented architectures, however, and I've noticed that shifting from an OO mindset to an SOA mindset can at times be more challenging than the switch from procedural to OO. Given that the guts of the web service implementations are often in OO, and these patterns can thus be applied there, has anyone seen any good treatises on SOA patterns yet, be it online or in book form? What I've seen has been pretty preliminary and basic. Given the immaturity of SOAs and the thusfar slow adoption of them, it's not surprising, but it would be nice to have some 'pattern gurus' apply their skills to both SOA patterns and the interaction between SOA patterns and the existing OO patterns.

    In the interim before the appearance of such works, I've been trying to keep an informal list of patterns I've unearthed through practice, but my ability to codify patterns cannot match that of someone like Holub. :-)

  • sounds promising (Score:2, Interesting)

    by magicmonster ( 795044 )
    This sounds promising. I've been waiting for another book besides design patterns by the gang of four, and specifically looking for one with nice Java examples. The other design patterns books I've found are all geared towards J2EE or the enterprise market. Does anyone have a quick table of contents or a list of patterns he covers?

  • Check out "Pattern Hatching" by John Vlissides (Score:4, Informative)

    by Eric Giguere ( 42863 ) on Tuesday November 16, 2004 @05:51PM (#10835861) Homepage Journal

    Design pattern fans should check out Pattern Hatching: Design Patterns Applied [amazon.com] by John Vlissides, one of the Gang of Four. Short, but interesting reading.

    Eric
    How to detect Internet Explorer [ericgiguere.com]

  • Another pompous "expert"? (Score:5, Informative)

    by Anonymous Coward on Tuesday November 16, 2004 @06:02PM (#10836003)

    Before perusing this discussion, you may want to get some perspective by reading Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments by Justin Kruger and David Dunning (Journal of Personality and Social Psychology,

    Well, I didn't know much about this guy. But anybody who defends his position by referring to this psychology paper doesn't score too high in my book. If you're not familiar with the paper, it basically asserts that stupid people don't realize how stupid they are. So referring to this paper is a subtle way of saying "you're stupid, and you don't know it".

    But I'll give him the benefit of the doubt.. after all some other pompous experts [dbdebunk.com] have referred to that paper yet raise important points based on sound theory. I.e., there is not necessarily a correlation between being an assmunch and being *wrong*.

    So now I read his papers on getters/setters and he claims this is "bad" because it assumes an implementation of the underlying value:

    double orderTotal;
    Money amount = ...;
    //...
    orderTotal += amount.getValue(); // orderTotal must be in dollars

    Excuse me but having to declare orderTotal to be any particular type is a *JAVA* thing, and not universal to OO programming. In Ruby for instance:

    orderTotal += amount.value

    No types or assumptions here. Since Ruby is fully OO, this will work even if amount.value returns a Fixnum, a Float, or a SomethingElseEntirely.

    He says a "better" way is:

    total.increaseBy(amount );

    But this is just syntax. In Ruby I would just write:

    total += amount

    And it doesn't matter what the types (classes) are.

    Poor guy is stuck in a statically typed Java hell, with distinctions between primitive types and objects, of course he's gonna think getters/setters are evil and he's gonna become obsessed with keeping his data hidden in a box or behind opaque methods! I can just imagine his code filled with thousands of builder objects with 2-3 levels of abstraction .. and it will just be a grotesque simulation of a true dynamic language in the end, with everything completely decoupled.

    I don't know if I should bother reading any more of his writings since I don't use Java.... is the rest of his work "how to get around Java's shortcomings" or is there something a general purpose OO practitioner might find useful???

    • Poor guy is stuck in a statically typed Java hell, with distinctions between primitive types and objects, of course he's gonna think getters/setters are evil and he's gonna become obsessed with keeping his data hidden in a box or behind opaque methods! I can just imagine his code filled with thousands of builder objects with 2-3 levels of abstraction .. and it will just be a grotesque simulation of a true dynamic language in the end, with everything completely decoupled.

      This is totally off base. You're

    • Whoever modded this post as +5 Informative is a fucking moron. The guy admits he doesn't know Java, and yet he makes arguments about how Ruby is better than Java. The way he talks about primitive types, you would think he thought there was a "dollar" type in Java. The purpose of the comment in the code is to remind the programmer that he wants the value in dollars, not billions of dollars, euros, yen, etc. The only thing the post is +5 informative about is how much of an idiot the poster is (and maybe h
      • Indeed. The irony is the comment opened with a negative reference to a paper on how people with substandard knowledge often presume themselves to be more capable than they are. Looks like he walked right into that one.

  • Should be titled "Holub on Java Patterns" (Score:4, Insightful)

    by pammon ( 831694 ) on Tuesday November 16, 2004 @06:16PM (#10836181)
    The dirty unacknowledged secret of design patterns is that they're strongly coupled to a language. For example, switching from a statically typed language like Java to a dynamic one with forwarding substantially changes the approach to Factory, Proxy, Singleton, Observer and others. In fact, they're often rendered trivial. The claim that the approaches described in the book apply to any language is just not true. These patterns are for Java and Java-like languages.
    • There's some truth in what you say, but you're overstating it. Some patterns fit more easily in some langauges, and indeed some are unnecessary in more dynamic languages.

      However, the original Gang of Four patterns book rather disproves your assertion:

      " The dirty unacknowledged secret of design patterns is that they're strongly coupled to a language. "

      The examples in that book are all given in C++ and Smalltalk, which are pretty much at opposite ends of the O-O spectrum, and yet the patterns are applicabl
    • There is a good presentation on how the dynamic languages make the patterns trivial/unnecessary; written by Peter Norvig. Check out http://norvig.com/design-patterns/ [norvig.com]

  • The examples sound great, but... (Score:5, Interesting)

    by javaxman ( 705658 ) on Tuesday November 16, 2004 @06:36PM (#10836379) Journal
    I'd like to see the details of the first section.

    I mean, yea, "getters/setters are bad", in public APIs. Getters are bad- unless you need to vend an object and can't afford the overhead of creating entirely new instances when you do so. Setters are _definitely_ bad- unless they're private or are data that act as input for your object, which it recieves from controller-layer objects.

    Sure, "inheritance is dangerous" as anyone who has ever written an object-oriented program from scratch and had to modify it can tell you. Inheritance is also the key to code reuse, and can be very powerful when done correctly- do you really want to re-write a section of logic that's shared by 5 other objects ?

    These things have their place. They're good targets for "is evil" [javaworld.com]-type articles [javaworld.com] because they're often used when they should not be. But to call them "evil" and "bad" without proper qualification? It smacks of unprofessional behavior, at best.

    I'm a bit puzzled by claims that use of getter/setter methods and, more puzzling, inheritance, are indications that you haven't solved your problem in an object-oriented manner, or that your problem isn't object-oriented... because, well... not all problems are best solved by object-oriented methods, even if you're using an object-oriented language to do so. Sometimes, you need a variable and a loop... what's wrong with that?

    At some point, my model code is going to have to give my view code some objects to display... what, I'm not supposed to use getters there? At some point my view code is going to want to tell my model code about an object the user modified... I'm not supposed to use a setter there? I often think folks who write such blanket statements as "accessors are bad" are just trying to spark some flames.

  • Intuitive (Score:5, Interesting)

    by roman_mir ( 125474 ) on Tuesday November 16, 2004 @06:45PM (#10836468) Homepage Journal
    I didn't find it in many programmers I worked with, but personally I find all of the advices in this book intuitive. What I did find in many programmers is the rigidness they assume when someone questions their position on some specifics. I remember a few conversations I had where I questioned the entire OO paradigm, the people look at you as if you are mad.

    But the reason why I questioned the OO paradigm was not the paradigm in its purity, but the implementations that I so often saw in real life. Some of the architectural designs that I witnessed did not make any sense and were artificially created to be more complex than the problem at hand required. What is worse, I have seen 'architects' who got into those positions without any merit. I have witnessed architects who think their position is justified because they spend another 4 weeks in the beginning of every project 'rethinking' the ACLs. I have witnessed an 'architect' that was supposed to design a system, but who instead sat down with a programmer, did a bunch of handwaving, and left the programmer without any idea and without documentation on how things are supposed to be done, and it was not a simple thing for that guy who was still a beginner. I cannot count the number of times where I (as a contractor) in different companies was put into a position where I had to solve the problems created by these 'architects' as well as by 'managers' and the marketting people.

    Yes, I remember having a conversation about getters, setters about 4 years ago, I was convinced that those things are a horrid idea as well as extends (for almost the same reasons given in the article). I was attacked on more than just the techno-level. It is hard, it is not easy at all to work around bad design decisions, where someone just does something because it is either a pattern they read, or the marketting says it has to be done that way because there was this meeting with an IBM guy, who bought all the managers year-long golf memberships.

    What I appreciate in people is the ability to think for themselves and to make decisions on when something is appropriate. I am also a realist, I know that noone on this planet can be perfect 100% of the time. We get tired, we have schedules, we just want to do things fast and dirty, we resist structure because it is easier that way. But those of us who are good enjoy going through all of this nonsense and figuring out sensible ways to still deliver a good system.

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close