Patterns - code readability (general/lame question)
1 posts in topic
Flat View  Flat View
Older Post First |   Reply to Topic
TOPIC ACTIONS:
 

Posted By:   Maxim_Hodanovich
Posted On:   Sunday, January 16, 2005 01:22 PM

I've just started with design patterns and trying to use them at once. And i'm in doubt whether patterns always improve (not make worse at least) readability of code. For example, the Abstract Factory pattern breaks the client class - concrete server class dependency, and this seems to be good, but on the other hand, when I examine smb. else's code, it may be annoying to find where the factory instance is created (factory global variable is initialized). And there may be even several factory implementations... so I hope you see what I mean, and obviously this is not exactly about Abstract Factory, but about the corresponding OOP principles in whole. So we need completely different *organizational* approach    More>>


I've just started with design patterns and trying to use them at once. And i'm in doubt whether patterns always improve (not make worse at least) readability of code. For example, the Abstract Factory pattern breaks the

client class - concrete server class dependency,

and this seems to be good, but on the other hand, when I examine smb. else's code, it may be annoying to find where the factory instance is created (factory global variable is initialized). And there may be even several factory implementations... so I hope you see what I mean, and obviously this is not exactly about Abstract Factory, but about the corresponding OOP principles in whole.


So we need completely different *organizational* approach
(with UML documents, and so on... or at least just documentation) that is completely passed by all the companies I ever worked for (not your case?). Without that I rather should keep off the subject to not make things worse. All we have to work in "real world" and it seems to me the world (read management) must be changed to make Design Patterns be really the choice. Or am I too pessimistic?


P.S.sorry for such a (off-topic?) question

   <<Less
Report | Quote This | Send private message | Reply | Print

Re: Patterns - code readability (general/lame question)

Posted By:   Anonymous  
Posted On:   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.

Report | Quote This | Send private message | Reply | Print
About | Sitemap | Contact