Programmer's Notes

Preface

This is an introductory post to the series, where I’ll cover all design patterns, their usage, diagrams. Besides patterns, I am going to guide you through the principles of the high-quality application design. We’ll start from these principles (GRASP), and then advance to patterns, see how they use these principles and develop several systems (architecture only). The whole series will take 10-15 posts. However, I don’t have exact plan yet So, let’s go!

So what we’re talking about?

Actually, design pattern is no more, than a proven solution to some common problem. When saying “problem” I mean things you face with when developing the application architecture. These solutions are intended to make you application better – more extensible, flexible, simple.

Common examples of design problems (Let’s agree that in this series “design” means application, not graphics or DB design) are:

• Organizing access to the shared resource. This can be application object, DB abstraction object, Session object or other similar things. Main problem is that they should be created only once and accessed in every method easily. Singleton pattern solves this problem.
• Creating the easily extensible application. For example, code shopping cart in the way, that allows to add new payment or taxation modules easily. Adapter pattern saves us here.
• Providing the simple interface for accessing features of the application or application module, hiding all the underlying classes/functions from the user. Façade pattern does this.
• Separating data from data processing and from presentation. You’ve definitely heard about MVC (Model-View-Controller) – that’s also a pattern!

So patterns are everywhere in OOP and knowing them is essential for high-quality and extensible application design.

The basics

However, patterns themselves are implementation of the 9 basic principles (GPASP – General Responsibility Assignment Software Principles).

All OOP design is about creating real-world abstractions (classes), design methods (responsibilities) and their interaction. The key thing to good architecture is assigning responsibilities to the classes correctly. GRASP deals exclusively with this problem. We’ll go through all of them:

• Creator
• Information Expert
• Low Coupling
• High Cohesion
• Controller
• Polymorphysm
• Pure Fabrication
• Indirection
• Protected Variations

Today we’ll start from the first principle.

Creator

The most common problem in OO design is “Who should create object X?” This principle states, that object A should create object B if:

• A contains or aggregates B (e.g. Object User should initialize object Address)
• A records B (saves to DB or file)
• A closely uses B
• A has the initialization data that should be passed to B when object is created

If any of these conditions are true, then A should create B. Now let’s demonstrate how these principles work in real examples.

A contains or aggregates B

Consider we have table. Common table consists of desk and legs.

If we use object decomposition to program the table, we’ll get 3 classes:

• Table (blue box on image):
  • Desk (light grey)
  • Leg (wooden)

Object decomposition basically means breaking some entity into parts and representing each part with a object. These parts can be decomposed further. For example, we can break Table into Desk and Leg. And then break Leg into Screw, Plank. In complex system there is a number of such levels.

If we start programming this, we can go in 2 ways. For example, we don’t want to use the Creator principle and will create Table class as follows:

Then Desk and Leg classes:

Yes, Desk and Leg classes are really the same cause they both are parallelepipeds. So we can create Parallelepiped class and extend both of them from it. We’ll do it later, now we’re talking about object creation. The above classes can be used in the following way:

Yes, the object is created, but large part of the creation logic is outside of the object. The class user (the programmer who is using this class) should know the internal structure of objects to create the whole object. This approach is inefficient when we deal with large application; on the other side, such solution can’t be reused without changing the code. And it violates the first condition of using the Creator principle. Either Desk and Leg are parts of the Table object, so it should take care of their instantiation. So let’s learn how to solve such task correctly:
We’ll create constructor for Table class with parameters:

• Width – width of the table
• Length – length of the table
• Height – height of the table
• DeskHeight – height of the desk
• LegSection – (assume we want square legs)

So the end-user of the class should specify only these 5 parameters, we don’t ask him to create parts of our object. OK, let’s code it:

Desk and Leg classes remain the same. So here we followed the first condition (actually, the most important) and got nice architecture.

A records B

After detailed discussion of the first condition, this should be quite evident. Usually if some object saves another one, it is his part. For example, we have some system with users. Each user may have several addresses. So Address will be the part of User (it is quite logical to design so), and User object will save all addresses in one field (Using serialization). And when loading, it will load the address info from DB and create Address objects. This is example of both 2, 3 and 4 item. The User object saves Address. User object has initialization info for Address and user object closely uses Address. By the way, first item is also here, Address is part of User object.
As you see, all these conditions often go together.
I think, that the final 2 items should be evident.

Further development

Tasks for improvement your skills:

• Extend both Leg and Desk from the Parallelipiped class
• Implement getHeight() method for Table, Desk and Leg. Hint: In Leg and Desk classes it should simply return height. In Table class it should return sum of leg height and Desk height
• Implement setHeight method for all classes. Hint: when setting height for table, you should actually increment Leg’s height
• Implement Saving and loading from file or DB. Hint: actually you have to save only 5 parameters – those passed to table constructor. So when saving and loading Table class with interact with Desk and Leg classes. And when loading – will create these classes.

Information Expert

The last condition of applying the Creator principle shows, that object A should have all info about B to create it. In other words, A should be Expert in info about B. Information Expert principle helps us assigning all responsibilities in the project. Real-world application usually holds a number of classes, that perform hundreds and thousands of actions, so it is essential to assign responsibilities correctly. The principle itself is fairly simple – you should give the responsibilities to the object it has information for. For example, assigning Table class responsibility to create Desk is correct because it has info about it. Assigning User responsibility to save data to DB is also correct, because User holds data about user and can perform this task without any other objects (assuming it deals with DB without DB abstraction layer). And assigning User to save information about Group is incorrect, because User will have to “ask” Group about it’s properties – ID, name, access rights etc. in order to save it correctly. In this case it’s much better to assign Group responsibility to save itself. And Use can call save() method on Group object.

In the next post I’ll cover Low Coupling and High Cohesion principles and illustrate it with practical examples. Subscribe to RSS not to miss it!
Feel free to ask any questions in comments or by email: konstantin.mirin[at]programmersnotes.info

Further reading

• GRASP
• Larman, Craig (2005). Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). Prentice Hall PTR. ISBN 0-13-148906-2.

Related posts:

1. Low Coupling and High Cohesion – GRASP (Design patterns series) Low coupling When designing some architecture, you face with the...

Related posts brought to you by Yet Another Related Posts Plugin.