Programmer's Notes » grasp

Low Coupling and High Cohesion – GRASP (Design patterns series)

Konstantin Mirin — Tue, 06 Oct 2009 06:00:40 +0000

Low coupling

When designing some architecture, you face with the problem “which object should perform X task?” We discussed this question in my previous post in this series. There we noted, that object should perform the tasks he has enough info for. He should be an “expert”. But because one of the main OOP characteristics is interaction between objects, it’s often hard to answer this question.

Introducing example

Consider you should print the table parameters (see What is OOP post for this example). There are tables of 2 types: square and circle ones. Square has parameter “side”, circe has parameter – “radius”. And we need the table:

Tables list

Sure, we can create a class Lister and method Lisert::out(). But what logic to place there? We can go with something like this:

class Lister
{
public $tables;
public function out()
{
echo "+———-+———–+———+
| Type | parameter | value |
+———-+———–+———+\n";
for ($i = 0, $s = sizeof($this->tables); $i < $s; $i++)
{
if ($this->tables[$i] instanceof CircleTable)
{
echo ‘| Circle | radius | ’.sprintf(‘%5.2f’, $this->tables[$i]->radius)." |\n";
}
else
{
echo ‘| Square | side | ’.sprintf(‘%5.2f’, $this->tables[$i]->side)." |\n";
}
echo "+———-+———–+———+\n";
}
}
}
?>

Identifying the problem

However, this method is strictly linked to using only CircleTable and SquareTable, it will not work without CircleTable and adding other table types is impossible. This can be imagined like this:

Classes coupling

Notice that since Lister class uses CircleTable and SquareTable, they can’t be used along. This picture illustrates it – they are coupled together.

Coming up with a solution

The correct variant of solving the task of table output is the following.

Refactor Table classes putting the output logic, that is specific to the table into the class
Use these new methods of table classes in the Lister::out method

Enough talk, let’s walk!

class CircleTable extends Table
{
public $radius;
public function __construct($r, $h)
{
parent::__construct($h);//calling the constructor of the parent class, passing height there.
$this->radius = $r;//setting the radius
}
public function getSquare()
{
return $this->radius*$this->radius*M_PI;
}
public function out()
{
echo ‘| Circle | radius | ’.sprintf(‘%5.2f’, $this->radius)." |\n";
}
}
class SquareTable extends Table
{
public $side;
public function __construct($s, $h)
{
parent::__construct($h);//calling the constructor of the parent class, passing height there.
$this->side = $s;//setting the side
}
public function getSquare()
{
return $this->side*$this->side;
}
public function out()
{
echo ‘| Square | side | ’.sprintf(‘%5.2f’, $this->side)." |\n";
}
}

And we’ll use these methods in the Lister class:

class Lister
{
public $tables;
public function out()
{
echo "+———-+———–+———+
| Type | parameter | value |
+———-+———–+———+\n";
for ($i = 0, $s = sizeof($this->tables); $i < $s; $i++)
{
$this->tables[$i]->out();
echo "+———-+———–+———+\n";
}
}
}

Running the code with the same data will give us exactly the same thing. But only one difference – this code is easy to maintain, change and expand. We can imagine this structure as following:

Low coupling illustration

For example, if we need one more table – triangle – we just add this class and then – created object into the List::tables property and that’s all. It will be printed out.
Here is the code:

class TriangleTable extends Table
{
public $side;
public function __construct($s, $h)
{
parent::__construct($h);//calling the constructor of the parent class, passing height there.
$this->side = $s;//setting the side
}
public function getSquare()
{
return $this->side*$this->side*0.433;
}
public function out()
{
echo ‘| Triangle | side | ’.sprintf(‘%5.2f’, $this->side)." |\n";
}
}

And now add this table to the test script:

require_once(‘Table.php’);
require_once(‘Lister.php’);
$list = new Lister();
$list->tables = array(
new CircleTable(5, 90),
new SquareTable(2, 85),
new SquareTable(8, 100),
new TriangleTable(7,150),
new TriangleTable(10,120),
);
header(‘Content-type: text/plain’);
$list->out();
?>

And we’ll get the following table with no modifications in the Lister class:

Modified list of tables

Note, that we can populate tables list from the DB table and no code will be changed. Adding new table type is very simple – you just develop the class similar to CircleTable or SquareTable and then use it. No more changes needed.
This technique when you do your best to write the isolated pieces of code, which can be reused separately is called “Low Coupling”, your goal is to create classes in such a way that they do not depend on each other or check these dependencies preventing runtime errors.
Sure, that’s the goal, it can’t be achieved in full, but you should aim to do this.

High cohesion

When you do your best to implement the Lout Coupling principle, you write your code in a small portions, and each of them does some definite task. And since each class is small and does only one or several cohesive jobs, you get High Cohesion in your code.
These two principles go together. When you fulfil one of them, you automatically follow another one.

Summary

Putting it all together, we may say that Low Coupling principle requires writing isolated pieces of code, that form complex logic only by interacting with each other, not by themselves. And While following this principle, our little parts automatically become focused on one task, so they become cohesive. This way we fulfil both principles at once.
And good OO-design follow all GRASP principles at the same time just because they characterise nice application design.

What can you add here? Maybe you’ve got some questions? Feel free to ask here in comments or by email.
Grab the code of examples here.

Liked the post? Bookmark it

Hide Sites

No related posts.

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

Creator and Information Expert principles – GRASP (Design patterns series)

Konstantin Mirin — Sat, 28 Mar 2009 13:37:32 +0000

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).

GRASP and patterns

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.

Common table

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:

class Table
{
protected $desk;//desk object
protected $legs;//array of legs
public function __construct(Desk $d, $l)
{
$this->desk = $dd;
$this->legs = $l;
}
}

Then Desk and Leg classes:

class Desk
{
protected $width;
protected $length;
protected $height;
public function __construct($w, $l, $h)
{
$this->width = $w;
$this->length = $l;
$this->height = $h;
}
}
class Leg
{
protected $width;
protected $length;
protected $height;
public function __construct($w, $l, $h)
{
$this->width = $w;
$this->length = $l;
$this->height = $h;
}
}

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:

$desk = new Desk(900,900,20);//90 cm width, 90 length (square) and 2cm height. A normal table for kitchen
$legs = array(
new Leg(40,40, 880),//4×4 cm square and 88cm height. 88cm leg + 2 cm desk = 90cm full height
new Leg(40,40, 880),
new Leg(40,40, 880),
new Leg(40,40, 880),
);
$table = new Table($desk, $legs);

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:

class Table
{
protected $desk;
protected $legs;
public function __construct($width, $length, $height, $deskHeight, $legSection)
{
$this->desk = new Desk($width, $length, $deskHeight);
for ($i = 0; $i < 4; $i++)
{
$this->legs[$i] = new Leg($legSection, $legSection, $height – $deskHeight);
}
}
}

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

Programmer's Notes » grasp

Low Coupling and High Cohesion – GRASP (Design patterns series)

Creator and Information Expert principles – GRASP (Design patterns series)

So what we’re talking about?

Further development

Further reading