Monday, January 17, 2005 02:11 PM
The overuse of patterns certainly can lead to obfuscated code. Before introducing a pattern it's therefore a good idea to be really sure that you need it, that there isn't a simpler approach that will work equally well.
It's not my experience that the usage of patterns typically increases the need for documentation, at least not if you are pattern literate. Recognizing a pattern inside the code actually can help a great deal in understanding its structure. After all, if you don't use the pattern to solve your design problem, you will need to use a different solution - one that typically isn't as well known and more coupled. In your Abstract Factory pattern you might need to contaminate your code with a bunch of switch statements at different places, whichs logical coupling might not be that obvious to the reader.
It's also a question of the tools you use. With a modern IDE, such as Eclipse or IntelliJ IDEA, it's just a matter of a few keystrokes to find all the implementations of an Abstract Factory interface, and all the places where they are instanciated.
And last but not least, it's also a matter of learning to read the code differently. When you read good OO code, it often feels as if all the code actually isn't doing anything, but just delegating to other objects. If you are used to reading more procedural code, you don't stop wondering what all those method calls actually do and where the real work is done. Reading OO code simply needs to get used to, to learn to trust the objects you are using. For example, when reading the client of an Abstract Factory, in most cases I don't care at all where the instance is coming from or how it might be implemented. What I'm interested in is how the client code uses it, and the instances it gets from it. Having the abstraction of the Abstract Factory helps me to concentrate on the important business logic of the client, without being distracted by the details of object creation.
I hope this helps you in getting an idea of where the application of design patterns - and the principles of OOP in general - should lead you to. Don't hesitate to use patterns, but also be observant to wether they really help you, and don't hesitate to remove a pattern if you find that it's more trouble than its worth.