Holub on Patterns

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.

Comments

Witch doctors

[MikeMacK]

Still, if I could name this book, it would be Object Oriented Design Voodoo.

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

Official site

[the_mighty_$]

The official site is located here.

Getters/setters bad?

[d_jedi]

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?

[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?

[Misch]

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.

Re:Getters/setters bad?

[SpaceTux]

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?

[homebrewmike]

Here's a good explanation: http://www.javaworld.com/javaworld/jw-09-2003/jw-0 905-toolbox.html

Re:Getters/setters bad?

[FerretFrottage]

Look here

Re:Getters/setters bad?

[fizban]

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.

In the second case, you shouldn't provide getters and setters because you're breaking the encapsulation.

If you have classes with lots of getters/setters, then those classes are really just data objects and you should just make the members public and save yourself a bunch of typing.

Re:Getters/setters bad?

[Greyfox]

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.

Re:Getters/setters bad?

[fartrader]

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 objects represent units of encapsulation where *functionality* is built around cohesive sets of data. In other words its always wise to revisit how you have partitioned your design if your object model is rampant with such abstractions.. a pure data object really doesnt *do* anything.

Re:Getters/setters bad?

[UWC]

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, or at least not introduced widely to C++ until .net?

Re:Getters/setters bad?

[Dormann]

Read it again. He says that sub-classing is dangerous, not bad.

In the same sense that using a chainsaw is dangerous, but not necessarily bad.

Re:Getters/setters bad?

[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!

Re:Getters/setters bad?

[emiddlec]

The article Why getter and setter methods are evil (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.

Re:Getters/setters bad?

[GuyWithLag]

Funny, I allways thought that GUI widgets were THE example of OO-ness....

Re:Getters/setters bad?

[achacha]

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; }
public void setValue(int v) { m_value = v -5; }
private int m_value = 0;
}

Here the implementation hides away the logic which the user should not care about (this is a simplistic example, but you get the idea).

People should use patterns to make coding easier, not code so that you can use patterns.

Re:Getters/setters bad?

[chromatic]

Polymorphism a the building block of OO, not inheritance. It's a shame that so few popular languages make this clear.

Re:Getters/setters bad?

[philci52]

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.

Re:Getters/setters bad?

[fupeg]

Your "data object" is not an object at all. Read the most basic definition. 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.

Re:Getters/setters bad?

[Cyberfox]

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?

[alw53]

>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?

[marms]

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 (think: simple code). But there are a multitude of reasons not to. YMMV.

Re:Getters/setters bad?

[TheSunborn]

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

Re:Getters/setters bad?

[killjoe]

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.

Re:Getters/setters bad?

[KyleCordes]

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?

[kpat154]

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.

Re:Getters/setters bad?

[Greyfox]

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.

Re:Getters/setters bad?

[Canberra Bob]

"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 am curious how this shopping cart would operate if the item was never queried to find out its price?

Re:Getters/setters bad?

[bokmann]

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

Re:Getters/setters bad?

[Ryosen]

This is a bad approach. The Item object here is a representation of data. Any logic imposed on that data should not be encapsulated within the Item object itself. The addToCart() method is an implementation detail, describing one possible use of the item's data within this particular system. It is more appropriate to implement the addItem() method on the cart.

Consider this, the addToCart() method is implemented in the Item object. Elsewhere in the system, we want to implement an Invoice object. The Invoice object contains, among other things, an aggregate (collection) of Items. If we want to add an Item to the invoice, using the method described in your post, we would have to add an addToInvoice() method to the Item object.

Simple OO design tells us that the Item object has no business knowing the implementation of an Invoice (or a Cart or a Sales Report or a Catalog, etc). A data item should never be aware of (or care) how it's being used within a system. The maintenance effort alone would be a nightmare and cause the system to crumble. Consider: you change the process of how a cart adds items - what effect will this have on the invoice?

At a simple level, objects should be thought of in terms of nouns and verbs - what something "is" and what something "does". Keep these two concepts separate and you will be on the right track to good design.

Applicability to other forms of development

[nanter]

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

[magicmonster]

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

[Eric Giguere]

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

Eric
How to detect Internet Explorer

Another pompous "expert"?

[Anonymous Coward]

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 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???

Re:Another pompous "expert"?

[MarkusQ]

I think you are missing his point. In ruby, as in SmallTalk, or any other real OO language, "+=" is just a message (in this case, one that is automatically defined when you define "+"), to say that it's better or worse than another semantically equivalent message is just silly.

Yes, they are semantically distinct in Java, but that is a statement about Java, not about OO programming.

-- MarkusQ

Re:Another pompous "expert"?

[MarkusQ]

Strongly typed != Statically typed

You are confusing two concepts here. Smalltalk, for example, is dynamically typed yet it doesn't have all the casting about that C does; the typing is strong and dynamic while C's is static and weak/leaky. What gets you into trouble is the weak/leaky typing, not the dynamic typing.

-- MarkusQ

Re:Another pompous "expert"?

[elbobo]

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.

Re:Bring back procedural languages

[GlassHeart]

Just because code isn't object-oriented doesn't mean it's bad code, and anybody who tells you otherwise is just being dogmatic. However, there's a good chance that such code is less well-isolated from the rest of the system, and your one-liner fixes can more easily introduce unintended consequences.

One common pattern with maintained code is the cancerous growth of special cases to deal with new requirements. Over time, the special cases dwarf the original code, and it becomes very hard to even figure out what it's supposed to be doing.

Yes, OO doesn't solve all problems, yet "procedural languages"* are also well-known to have many problems of its own. OO is also easy to get wrong, as evidenced by your "have to throw them away periodically" observation. However, I can't help but feel that you're making conclusions based on limited and anecdotal evidence of failures.

* Many OO languages are procedural.

Re:Bring back procedural languages

[Greyfox]

Well the reason the technique was originally invented was that the DOD was spending way too much money on software maintenance. Of course, they were trying to maintain millions and millions of lines of Fortran, COBOL, BASIC and Assembler. Who's to say that improvements in structural techniques over the past decade or so wouldn't also have solved those problems?

Anyway, what I've noticed is that up until the past couple of years, not many people really had an idea of how to do Object Oriented programming all that well. Most programmers were faking it, mimicing the talk out of the various trade rags without really understanding the reasoning behind what they were doing. And you can make some pretty atrocious object oriented designs if you don't know what you're doing.

OOP doesn't need to be what you've seen any more than procedural code needs to be twisty mazes of GOTOs and global variables. It all boils down to the abilities of the guy writing the code.

Re:Bring back procedural languages

[guitaristx]

OOP is a wonderful thing because it enforces tons of those wonderful principles that are taught in Computer Science classes 'round the globe: encapsulation, abstraction, data hiding, "black-box" programming, etc. OOP is NOT supposed to be the end-all, be-all of programming, just as the creation of C and other higher-level programming languages was not to be the death of assembly programming.

What, so often, people fail to realize is that software is designed to be built in layers. See the TCP/IP stack, for instance. This allows for one of those wonderful OOP principles to work - abstraction. If the nature of the OOP system/API/et. al. is causing you more problems than it's solving, then I say it's not OOP's fault, it's the designer's fault. I don't believe that OOP is the solution to all problems - some problems are square, and some programming paradigms are round. Problems arise not because of the evil nature of OOP, but because someone tried to pound a square peg into a round hole. OO languages and systems give you the ability to make things object-oriented, but none that I've seen prevent you from using procedural programming techniques when your square programming problem doesn't fit nicely into a round OO hole.

Generally, I've found that people who hate OOP were forced into using it without getting enough exposure to it to appreciate it. Nobody's gotten rid of procedural programming, just like nobody's gotten rid of assembly programming. We just have higher-level tools and paradigms for dealing with high-level programming tasks.

Should be titled "Holub on Java Patterns"

[pammon]

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.

Re:Should be titled "Holub on Java Patterns"

[pammon]

Patterns are often applied as a substitute for missing language features. Using the Decorator pattern makes little sense if you can add methods and variables to individual objects (like in Python or Self).

Re:Should be titled "Holub on Java Patterns"

[rivermaker]

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/

Try Perl's non-OOP equivalents

[onlyjoking]

Philip Crow wrote a very original piece on how to avoid OOP and still use patterns with Perl's special built-in features

http://www.perl.com/pub/a/2003/08/15/design3.htm l

The examples sound great, but...

[javaxman]

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"-type articles 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

[roman_mir]

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.

Re:Bring back procedural languages

[LordByronStyrofoam]

Object Oriented languates/programming wasn't invented for DoD. You're thinking of Ada, which, in it's original incarnation was an Object-based system but didn't support proper inheritance or polymorphism (Ada'82).

OO started with Simula and Smalltalk, with Simula67 being the object oriented base of C++.

And if you don't know what you're doing in a particular paradigm you usually end up with dreck nobody wants to maintain.

(not) Short Plain-English Version Answer

[IBitOBear]

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 these methods as "translation to the outside world".

That is, if you find yourself writing NewThing.setValue(OldThing.getValue() * 5) then you are no longer getting any useful work out of having "thing" in the first place, and this is bad. It's bad because you are requiring yourself/the world to reach behind a blined and operate on something that you hope will remain stable.

Accessors and Setters are "good", however, (my view, not his) when you lear to see them as moments-of-control that you wrap around the need to communicate "parts of thing" with the outside world. These moments of control may involve locking or provide you the opportunity for "lazy evalutation" of a "thingness" that might exist in any of several forms. For instance, in TCL all of the values exist as this mutable state of "string or whatever". If you are working with the value as a string then it is best represented internally as a string; if as an integer then as an integer; etc. So having a getValueAsString() and getValueAsInteger() accessors make sense as they have that opportunity to do things while communicating with the outside world.

Such an enlightened thing should, however, have a [+= int] operator, and that operator should be used in global preference to dong set(get()+X).

So it isnt "really bad" to offer the user the opportunity to communicate with your object, but if you find that the objects *prefer* to be tweaked via this communication, then you have made a mistake that will cost you a lot _eventually_.

In practice, you can avoid this trap by being liberal with the getters but stingy as heck with the setters.

For instance a network socket object should have a lot of getters for things like "local address" and "peer address" and "lcoal port" and "general health"; but you don't want to "set peer address then connect" you want to socket.connectTo(PeerAddress).

Anoter example is "const string & someImportnatValue()" where your object maintians some important string and you might want to let the world examine that important value. But you don't ever let the world "replace" that value whole-scale. You allow the world to opperate uppon the thing, which *may* change the string too.

So expose spesific items of interest through accessors, but only provide "operators" as a means of changing what must change.

After all, if someone can just set a value, then how do you maintian your invariants (requirements of state)?

If you have written a true operator that you have chosen to call "set", then your name is probably wrong at least.

It's a distinction between grays in many cases.

Rule of thumb: the code that changes a thing should be owned by the thing. If you are "borrowing out" some key value, operating on it in the wild, and then "putting it back in" you are probably making code that will cause you harm, because now everybody is "diddling" your state in their alien and undefined-to-you code.

It's bad to be everybody else's (deleted).

Ruby Needs Data Encapsulation Too

[Bbazzarrakk]

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 missing the point. This isn't about typing, it's about Data Encapsulation.

Pop quiz, in Ruby no less. You have a class:

class BankAccount
attr_reader :balance
def transfer_to(other_account)
...
end
end

When your balance is off at the end of the day, you know where to look for errors. One of your methods, probably transfer_to(), is causing the problem. Change attr_reader to attr_accessor though, and then where do you check? Answer: The Whole Wide World! Good luck finding it, you'll need it.

More-OO-than-thou religious fanatics

[Latent Heat]

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.

Draw thyself?!

[Anonymous Brave Guy]

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!

Getters and setters are not "evil". They are a design choice, as Holub himself acknowledges. If you have a lot of these for a particular class, this is often symptomatic of a confused design, but the author missed the point here. The bits you're supposed to hide are the individual aspects of an object's state that must satisfy various invariant conditions. It doesn't make sense to change these independently, because you might violate that invariant. Hence, you only provide operations on the class that change them collectively such that they still satisfy the required invariant conditions.

However, if something can be changed in isolation without violating any invariants, there's no harm in providing a mutator method to do it. That applies up to and including classes with no invariants ("structs") where you can sensibly modify any aspect of the state in isolation. Moreover, if some aspect of state has a meaning in isolation, there is no harm in providing an accessor method to look up that state, even if you wouldn't allow it to be changed directly because of invariant constraints.

Confusing this with the idea that an object should be the only thing that can do anything with itself (such as drawing itself on a screen) demonstrates a spectacular failure to understand the underlying issues here. In fact, it's easy to show this: consider an operation where two or more user-defined types are involved, and you can't restrict all the knowledge about each object to that object and still perform the operation. Attempting to do so often results in exactly the problem with Holub's "draw thyself" example: it tightly binds two separate subsystems, forcing one class to live in both of them, with all the attendant spaghettiness that brings.

Now, Holub clearly realises that mixing UI code with business logic has unfortunate problems. He can protest about inner classes and facade patterns all he likes, but the fundamental design concern -- coupling the UI system to a data-handling system -- is still there. The only way to break the bad coupling is to separate out the facade code or whatever from the original class, and put it in a UI-based layer where it belongs. Of course, that probably requires using some form of accessor methods, which takes up back to where we started.

Who is this guy anyway, and why do some people here think he's good at this stuff? I honestly haven't heard of him before, and I'm fairly open-minded, but I'm not forming a good impression from reading a couple of his articles that people have cited in this thread.