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

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

Coming up with a solution

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

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

Enough talk, let’s walk!

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

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

And now add this table to the test script:

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

Modified list of tables

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.

Websites, that aggregate something become more and more popular because we need all information available in one place and accessed fast and easily. From time to time, you come across with tasks, that require retrieving some data from the password-protected area. For example, I use Guru.com for my job search. They post lots of the projects there, but they don’t offer convenient listing and filtering. So I developed my own tool, that grabs everything from there and ranks it all in the way I need. So, we’ll take a look at different types of password-protected areas and see how to deal with any of them

Cookie-based authorization

We’ll start from the most popular type of authorization First, let’s take a look, how data goes between the user and the server:

Cookie-based authentication

So all we have to do is:

1. Send login request
2. Catch cookie
3. Send all data requests we need

The second part is done automatically, so we can just focus on authentication and data retrieval.

Implementation

We’ll basically need 3 functions:

• requestContent – this will make actual HTTP request to the URL we provide with parameters we provide (POST, GET variables, HTTP_REFERRER etc)
• authenticate – this will send authentication info to the server using the requestContent function
• getPage – this will actually get data we need using the same requestContent function. Actually, you may use requestContent instead, but you’ll definitely want some post-processing the result, for example, fetch some info. So it’s better to define a separate function, that does it.

So let’s go! I’ve created 3 files: config.php where we’ll store config data, functions.php where we’ll define out functions and index.php, that actually carries out the job.
config.php follows:

In functions.php I define our 3 functions. requestContent looks as following:

Basically, here we init cURL, and get the handler. It is similar to the fopen(). Then we set all options we need and finally execute the HTTP query and return result.
Authentication is based on the previous function, that carries our all the low-level job. We only have to examine our login form and determine, what variables to send. So, open the login page of the service you want to access, find the <form> tag and copy the login URL. You’ll have to put it into the config.php file. Then see what fields are there. Note, that there my be hidden fields also, note their variables and create an associative array for them (see the following code). If you’re not sure what variables are actually sent, you may use Live Http Headers plugin for the Firefox.
Usage is simple. Open the login page. Fill it in. Then start the plugin (Tools -> Live HTTP headers). Submit the form and see the number of queries are shown. You actually need only the first one – this is your request. See the screenshot:

Http headers

After getting result, you may parse it and see if you got a successful login. After you performed this query and got response, you’ve also got the session ID stored in cookie. You may open the cookie file and take a look yourself. After this you may perform any requests to the servic and it will respond as if you are logged user. The trick is that cUrl will send him cookies from the cookie file. And we have the session ID there or anything else that site uses for user identification.
So my getPage() function is a simple wrapper over the requestContent():

Basically, that’s all you need in order to get into the protected area. Now you’re free to do anything you want. Using regular expressions for parsing is the most common way to get the data from the page, so maybe you’ll need the tool for testing your regexps. I really recommend “The Regext Coach”, it greatly simplifies debugging

HTTP authentication

Another approach to the authentication, that is sometimes used in different control panels is HTTP authentication. You should have seen that – you’re presented with a standard screen, prompting for username and password. This username and password are sent with each request. You are not prompted fro them every time just because browser remembers it. To access such area, you don’t need any authenticate() function. You just pass login and pass with each request.
Here are modifications you should do in the above code:

That’s all I wanted to share with you today. Hope you fins it helpful! If you have any questions/comments, feel free to add them!

Quick Note on OOP

I didn’t create the Curl class or present solution as a class because I don’t think it makes my explanations more clear or the code easier to use. This is not full solution, this is just a technique and I tried to present the code in such a way, that you could use them with minimal changes. You can easily put that functions to the class

Further reading

• cUrl on Wikipedia
• cUrl home page
• PHP documentation on cUrl

Download code for the post

Liked the post? Bookmark it

Hide Sites

No related posts.

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

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

• 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

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

Liked the post? Bookmark it

Hide Sites

No related posts.

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

OOP stands for Object-Oriented Programming. What does it mean? And what’s the difference between OOP and procedural programming? We’ll go through all these terms, We’ll demonstrate the difference of these approaches and advantages of the OOP over procedural concept. Examples are for PHP, but concept is the same in all object-oriented languages.

So, let’s start with defining, what OOP is and how it differs from procedural programming. Just take a look around. For example, you see a table. Consider you have to program it. When using procedural approach, you focus on it’s behaviour (for example, you write function, that calculates height or that assembles it from the given dimensions). However, table has properties besides behaviour. When following procedural paradigm, we create variables for each property – height, width, length, square, weight. All that data – properties (variables) and behaviour (functions) describe the object from the real world – table. What’s wrong with this approach? Nothing wrong, everything is fine, when we’re dealing with one table.

Procedural programming – the problem

And now imagine if we have several table types – square, triangle and rounded. Consider the following task. We have to calculate square of every table. Let’s try to do this with procedural approach, without any objects. Each table has only one property, that we’re interested in – side for triangle and square and radius for rounded one. Now we’ll create 3 functions, that calculate the square. (see formulas for equilateral triangle and circle)

Everything is fine until we have to print list of tables with squares like:

To process it, we need one more parameter in our array – the type of the table. And adding it makes array a 2-dimensional one:

And now let’s program processing of these arrays (using the trick with for loop):

Yes! We did it – created all the stuff we had to and it works fine. But take a look at this. In the array we have to specify the table type, then check it and select the corresponding function. And how about dealing with 10 table types? Adding each type requires adding new calculation function and changing the printing one.

OOP – solution

And now we’ll take a look at the object-oriented solution. Maybe you’ve heard of the 3 principles of the OO programming – Inheritance, Encapsulation, Polymorphism. And all of them are used even in this simple example. But before plunging into the OO world, let’s see, what is object.
When developing, by saying “object” we mean some abstraction of the real world object (not always real, it may be an abstraction), that has some attributes (called properties or fields) and behaviour or actions (called methods).
So since object holds both it’s properties and behaviour, we can define 3 classes and use them all. Yes, we mentioned “classes”. Classes are “blueprints” for objects. Class describes, what properties the object will have, what methods will work with his properties and how. And when we need the object of this class to work with, we instantiate it.

Basically, you can imagine class as an empty pot. It has properties:

• contents
• volume

And objects of that class are:

• Big pot with honey (Contents = “honey”, volume=”big”)
• Little pot with water (Contents = “water”, volume=”little”)
• Medium-sized empty pot (Contents = “”, volume=”medium”)

You also can imagine the process of instantiation of the pot as the sequence of operations:

1. Take blueprint (class definition)
2. Create pot from clay (allocate memory according to the class definition)
3. Put something into the pot (Initialize properties with some values)

Steps #1 and #2 are done automatically by the programming language compiler (or interpreter), and the third step depends on the:

• Class definition – you can specify default values for the properties
• Class constructor – you can define special function, that takes care of attributes initialization. We’ll talk aabout them later.

So, now we have theory, let’s start coding.

In PHP, when we define the property without specifying it’s visibility, it is considered public. That means, that we can create an object and access it’s public property:

Other variants are private and protected. When we define property as private, it can be accessed only from methods of the same class. This is used for some internal variables. Protected is the same as private, but it can be accessed from the child classes also. Don’t worry if you don’t understand the concept now, we’ll go through this later.
Note: In other languages default visibility may be different! (e.g. C++ properties are defined as private by default)

Refactoring OO solution

Code refactoring is the process of changing a computer program’s internal structure without modifying its external functional behaviour or existing functionality. This is usually done to improve external or internal non-functional properties of the software, such as code readability, simplify code structure, change code to adhere to a given programming paradigm, improve maintainability, improve extensibility, or increase execution performance. (Wikipedia)

Now let’s take a close look at these classes. All of them have one parameter and a common method getSquare(). We can create the parent object – Table and extend these three classes from it. See the UML diagram:

This should be evident, but we’ll explain what’s there. First of all, we have class Table. It is a parent class for all tables. Then we have three derived classes (arrow points from child to the parent class), which override parent’s getSquare() method.
and the code:

Make it work!

So, everything is OK now and we can print the same table using defined classes. Unlike previous approach, we’ll have a simple array of objects here:

Note, that we don’t need any function selection, we just call getSquare() for any object. And since all of them have it (that’s why we defined common parent for them), we get correct result depending on the object we’re working with.
One more benefit is extending this code. Remember, when using procedural approach, to add new table type we had to add new function and modify the printing function. Using object-oriented approach, all we have to do is to create one more class. The printing function (which may contain complex logic or be hidden from the end-user) remains unchanged. So with OOP we write less and, at the same time, get much better solutions.

OOP principles explained

This principle, when different actions are performed when calling the same method for different objects, is called Polymorphism. Inheritance is the simplest thing for understanding – we used this to inherit (programmers usually say “extend”) three table classes from the one generic table class.

Finally, encapsulation is about hiding implementation details from the end-used. Let’s take our example; imagine that there are 2 persons. One of them is excellent mathematician and he created that 4 classed (base class – Table and 3 derived (child) classes). Other should show that list. With procedural approach he should take a look at the procedures and write code, that determines the object type and calls correct function. With OOA (object-oriented approach) he doesn’t have to know that. He just calls getSquare() and doesn’t care about anything.

Further improvements

To make these principles more understandable, let’s improve our code and add some data to the objects. Let’s store height of the table and then print volume, that it occupies. Volume=Square*Height. Square is calculated differently, formula for volume is the same. So we add new property to the parent class – $height. And new method – getVolume(). Note, we don’t change any child class at all!

And here is how it works:

Note, that we didn’t define $height or method getVolume() in CircleTable class, this is inherited from parent class. Don’t you think it’s very convenient?

By the way, we used design pattern here, which is called TemplateMethod – we defined method getVolume(), which uses method getSquare(). And getSquare() itself is defined in the derived classes. Read more about this pattern in my future posts

Using constructors

Now let’s do some more improvements – we’ll create constructors for the classes. Constructor is special function, that is called when object is created. We’ve already mentioned them. In PHP 5 constructor is defined as a special function, named __construct. It is a regular method, but it can’t return any value. However, it can be public, private or protected. Usually, constructors are private unless some design pattern is used (e.g. Singleton). Here is the code, that uses constructors for smarter object initialization:

Here is how to create such classes:

The following usage is the same, it just helps to initialize object attributes in one line of code, encapsulating some preprocessing. For example, we know that height can’t be negative, so we can correct definition of the Table class:

So you can see, using constructors is VERY handy.
Note, if you have the properties public (like in this example), you may still use $table->radius to access it.

Attributes and methods access

Finally, let’s take a look at the properties and methods visibility. As we already mentioned, there are three access levels:

1. Public – accessible both from class itself ($this->property) and from outside ($user->login)
2. Protected – accessible from the class itself and from it’s derived classes ($this->property, property may be defined in current class or in the parent one)
3. Private – accessible only from the class itself ($this->property, property should be defined in the current class)

To demonstrate this in action, we’ll modify the Table class and make it’s $height property private. Since it is used only in getVolume() method, which is also defined in the Table class, it should work fine. Also, we add a new method setHeight(). This will be used to modify height since we’ll not have access to it through $table->height. So here is UML and the code:

Note, that we changed constructor, not it doesn’t set the height itself, it delegates this to the special setter function, which perform all validation. This is a good practice – to have attributes of an object hidden and have getter/setter methods to access it. Why? Because this way you control, what is returned and what is set and can ensure that object’s properties are always correct.
When using this definition, we’ll not be able to access $height in CircleTable or TriangleTable. To enable this, we can either add getter method or make $height protected. First variant will allow everybody to get the height. Second variant allows to get the $height only within the derived classes (see protected access level above)

Glossary

• Class is a formal definition of some real object or it’s abstraction. It contains definition of it’s both properties and methods.
• Object is an instantiated class
• Property is a special variable, that represents some attribute of an object. Sometimes it is called “member variable”
• Method is a special function, that describes some behaviour of an object.
• Constructor is a special method, that is called when object is created. This is mainly used for the object initialization.
• Getter is a special method, that returns property value. Usually used for private or protected properties or for some kind of processing before returning.
• Setter is a special method, that sets property value. Used for private or protected variables or for some additional validation.
• Superclass is same as parent class or base class
• Subclass is same as derived class, child class, extended class
• Inheritance is an OOP principle, which is used to define some common behaviour in the base class and then extend it and use in the derived classes.
• Encapsulation is an OOP principle, which used for hiding implementation details from the end-user. (remember example with two programmers developing these table classes)
• Polymorphysm in an OOP principle, which allows different classes to behave differently when calling the same method.
• Design pattern is some standard proven solution to the common problem. For example, Singleton pattern solves the problem when we need some common resource in different places of an application. For example DB abstraction object.
• Refactoring is the process of changing the source code to make it work faster, look better, use better solutions, be better in support and future development

Further reading

• Creator and Information Expert GRASP principles
• OOP
• Procedural programming
• Constructor
• Design patterns: Singleton
• Design patterns: Template method
• Equilateral triangle
• Circle

Liked the post? Bookmark it

Hide Sites

No related posts.

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