Product Details

• Paperback: 688 pages
• Publisher: O'Reilly Media; 1 edition (October 25, 2004)
• Language: English
• ISBN-10: 0596007124
• ISBN-13: 978-0596007126
• Product Dimensions: 9.2 x 8 x 1.4 inches
• Shipping Weight: 2.8 pounds

Editorial Reviews

Review

This is a gimmicky book that actually works for once. It is an intelligent and well thought-out discussion of Java design patterns, and if you dont know what a design pattern is then this is an excellent way to find out. It is also an interested discussion of object-oriented design. I found that the authors often anticipated my reaction to their initial explanations and asked the questions that I would have asked had it been a lecture. - Mike James, VSJ, April 2005

Product Description

You're not alone. At any given moment, somewhere in the world someone struggles with the same software design problems you have. You know you don't want to reinvent the wheel (or worse, a flat tire), so you look to Design Patterns--the lessons learned by those who've faced the same problems. With Design Patterns, you get to take advantage of the best practices and experience of others, so that you can spend your time on... something else. Something more challenging. Something more complex. Something more fun. You want to learn about the patterns that matter--why to use them, when to use them, how to use them (and when NOT to use them). But you don't just want to see how patterns look in a book, you want to know how they look "in the wild". In their native environment. In other words, in real world applications. You also want to learn how patterns are used in the Java API, and how to exploit Java's built-in pattern support in your own code. You want to learn the real OO design principles and why everything your boss told you about inheritance might be wrong (and what to do instead). You want to learn how those principles will help the next time you're up a creek without a design paddle pattern. Most importantly, you want to learn the "secret language" of Design Patterns so that you can hold your own with your co-worker (and impress cocktail party guests) when he casually mentions his stunningly clever use of Command, Facade, Proxy, and Factory in between sips of a martini. You'll easily counter with your deep understanding of why Singleton isn't as simple as it sounds, how the Factory is so often misunderstood, or on the real relationship between Decorator, Facade and Adapter. With Head First Design Patterns, you'll avoid the embarrassment of thinking Decorator is something from the "Trading Spaces" show. Best of all, in a way that won't put you to sleep! We think your time is too important (and too short) to spend it struggling with academic texts. If you've read a Head First book, you know what to expect - a visually-rich format designed for the way your brain works. Using the latest research in neurobiology, cognitive science, and learning theory, Head First Design Patterns will load patterns into your brain in a way that sticks. In a way that lets you put them to work immediately. In a way that makes you better at solving software design problems, and better at speaking the language of patterns with others on your team.

Product Details

• Paperback: 487 pages
• Publisher: Apress; 2nd ed. edition (December 20, 2007)
• Language: English
• ISBN-10: 1590599098
• ISBN-13: 978-1590599099
• Product Dimensions: 9.1 x 6.9 x 1.1 inches
• Shipping Weight: 1.8 pounds

Editorial Reviews

Product Description

Backed by a tireless development community, PHP has been a model of language evolution over its 10+ year history. Borne from a contract developer’s pet project, these days you’ll find PHP powering many of the world’s largest web sites, including Yahoo!, Digg, EA Games, and Lycos. PHP Objects, Patterns, and Practice, Second Edition shows you how to meld the power of PHP with the sound enterprise development techniques embraced by professional programmers. Going well beyond the basics of object–oriented development, you’ll learn about advanced topics such as working with static methods and properties, abstract classes, interfaces, design patterns, exception handling, and more. You’ll also be exposed to key tools such as PEAR, CVS, Phing, and phpDocumentor.

What you’ll learn

• Write solid, maintainable code by embracing object–oriented techniques and design patterns.
• Create detailed, versatile documentation using the powerful phpDocumentor automated documentation system.
• Gain new flexibility during the development process by managing your code within a CVS repository and using the Phing build system.
• Capitalize upon the quality code of others by using the PEAR package management solution.

Who is this book for?

PHP developers seeking to embrace sound development techniques such as object–orientation, design patterns, testing, and documentation

About the Author

Matt Zandstra has worked as a Web programmer, consultant and writer for a decade. He has been an object evangelist for most of that time. Matt is the author of SAMS Teach Yourself PHP in 24 Hours (three editions), and contributed to DHTML Unleashed. He has written articles for Linux Magazine and Zend.com. Matt works primarily with PHP, Perl and Java, building online applications. He is an engineer at Yahoo! in London. Matt lives in Brighton with his wife Louise, and two children, Holly and Jake. Because it has been so long since he has had any spare time he only distantly recollects that he runs regularly to offset the effects of his liking for pubs and cafes, and for sitting around reading and writing fiction. Learn more on Matt's website, getInstance.

The Registry Pattern Reexamined

March 26th, 2010 @ 7:00 am Last July, I wrote about the registry pattern and some of its advantages. These advantages include the ability to access objects across different areas of your application, and the storage of objects for later retrieval. Much of the debate in the comments focused on whether or not the registry pattern was suitable for today’s object-oriented development, and some of the arguments focused on whether or not the “global scope” was a good place to have objects. For me, over the last few months, I’ve discovered two reasons why I advise against the Registry Pattern: first and foremost, it discourages unit testing, and secondly, it discourages good design. Unit testing is predicated on the assumption that you are testing small, discrete units of code that do not have dependencies. This requires that developers do everything they can to either remove dependencies or mock them in such a way that the dependencies are neutralized as contributors to the failure of the unit being tested. In PHP 5, objects are not copied when assigned; instead, their address in a hash table is copied. This means that if you retrieve an object from the registry, and then modify it, every subsequent retrieval from the registry will reflect that modification. The reason this creates a significant issue is that it prevents you from testing a discrete unit of code. Now, instead of one thing being the variable in a test failure, there are two: the unit of code being tested and the object it retrieved from the registry. Any time there is more than one possibility for failure, the effectiveness of the unit testing is diminished. As a side note, the same holds true of singletons: modifications to the singleton object will be reflected in every other test performed during that request, thus reducing the efficacy of the unit tests. Secondly, I’ve found that the registry pattern promotes poorer design overall. The reason for this is clear: because you can store an object for later use, there is no need to consider the path through the application that the object might otherwise need to travel. There’s no determination where, when and how to get the object to where it is needed. You can simply pull it from thin air on demand. This leads to developers being lazy about their architecture, and ultimately leads to poorer code (which you can’t determine through tests because the objects keep changing during testing!). Dependency injection forces developers to think about why they’re doing what it is that they’re doing. Moreover, using dependency injection means that you’re more likely to employ good development practices like abstraction, composition over inheritance, etc. The reason for this is because as a developer, when you start injecting three or four or five objects, you begin to consider why; this often leads to a refactoring, and ultimately a better finished product. As I stated before, design patterns are not the problem, and each design pattern has an important reason for existing and solves a very real problem. The registry pattern shouldn’t be forbidden or never practiced, but it should be practiced sparingly, along with all other design patterns, because it isn’t a one-size fits all solution. The original work of Brandon Savage.

High level classes should not depend on low level classes. Both should depend upon abstractions. Details should depend upon abstractions. Abstractions should not depend upon details.