Updates
Latest Tweet
What's New?
Check out for latest innovation, a computer based training video collection
Like this Page
Holub on Patterns: Learning Design Patterns by Looking at Code Review by Marc Grundfest
Caveat Utillior
While this is a worthy and useful effort it is marred by an excess of polemic compounded by a lack of humility and a dirth of references as there are none. Mr Holub is entitled to his opinions and also his polemic but the lack of references and a tenancy to paint the world both black and white creates an impression that Mr Hollup considers you, the reader, a prop or straw man in his one man play. I must caution the prospective reader to do his or her homework before, during, and after reading this work. Indeed I would actively discourage anyone from reading this book who was not well versed in OOD/OOP. This is because the world according to Holub is at variance to what you have been taught. This is not because the rest of world is wrong. It is because MR Holub likes to make a bigger splash than necessary to make very minor points.
I will deal with the minor transgressions first. Whatever the pedagogic virtue of bombast in a class room setting, the formaily of the written word argues for a much defter touch. For example
Getters and Setters are evil : now your are compelled to prove something. Notice that 'Considered Harmful' is not sufficient for Mr Hollub -- but now you must prove your case. This he not only fails to do, but mares his argument further by failing even to educate. He asserts that getter and setters violate encapsulation by revealing implementation details. He claims that if you reimplemented a class you are required to change the getters and setters. You will know that you have mastered OOD when you find this as funny as I do. First the term re-implement means to change how the class is built, but in such a way as to preserve the interface. If the interface must change the it is not a re-implementation it is a redesign. I will spare you the details but this is why design is often done first,and why XP is not always the best approach. Curiously MR Holub does not conclude that XP is evil, nor does he even realize that he as confused the concepts of implementation leakage with information leakage, nor that not all information leakage is bad. It goes downhill from there-- before he is done he will claim that putting UI code in a data Object is not a bad thing and that its not really UI code because it is only AWT.
This is laugh out loud funny.
Now it is true the the overuse of accessors is a 'smell' that your code is not as OO as it should be, is it worse than being bound to a soon be obsolete GUI layer ( AWT does not generate HTML or AJAX) or being unable to share data in an unencapsulated form with the rest of the enterprise via the -- oh right --whats that thing we have been using for 30 years --the relational database.
Now the book does have value, But Getters and Setters are not evil. First defining them does not leak implementation details-- they are part of the type safe contact that you should be using to limit access on an as needed basis. Only when they are referenced do they create a coupling issue and even then it is only a bad as you make it -- that is if you think about the interface before you code, and you do not turn agile methods into a free for all ( What DiJkstra once called the cult of iterative design ) then you will not need to hide your poor design skills by reclassifying re-design as a reimplementation.
I have neither the time nor inclination to deal with Inherits is evil--but if you learn about the Liskov Substitution Principle you can deal with it for yourself.
Do not read this book as a bible. Challenge and verify everything. BTW one can't help but think that the lack of references is intended to make the verify step as hard as possible.....