I’ve graduated in March 2010 and I don’t need to visit university any more. However, I enjoyed studying there and I know what challenges my fellow students-programmers have. That’s why I continue the job started this autumn – computer club, we call it “Geeks’ Club”. Sure, we’re not true geeks there, but we tend to be So I’m helping students who’re interested in web-technologies and in object-oriented programming. I explain them things that are not covered in the standard university course. Things, that are more practical and they can be paid money for.

Here I’ll be covering both OOP and web-dev, but we’ll start from design hence OOP. The story began when some time passed after we started learning OOP at the club meetings and I decided that there is enough theory and separate examples, it’s time to build something practical that will be challenging for me too.
I thought of different systems, but finally decided to pick up the SMS notification one. It requires both user interface, database, API (my friends want to communicate to it from standalone Java and C++ applications) and overall application design. In addition, I’d like such system to be deployed at our university and it is interesting for me to create one.

Introduction

This is going to be a series of articles, I’ll describe the progress and challenges we come across as we proceed with development. I think this kind of posts will be interesting for those who study OOP and want to apply what they’ve learned to some practical things. I’ll try to guide my students through the process using the iterative development methodology.

We have meetings once a week (on Saturdays), so I’ll post once or twice a week, depending on amount of work done on weekends and my free time during the week.

I think, this series will contain around 10 posts. We’re going to share the work done as an open-source project. There is nothing to share at the moment, so I’ll give the link when we code something

System overview

Vision

Obviously, the main purpose of the system is to send SMS notifications to students or tutors. These notifications may be quite different – from the timetable changes to some announcements or even warnings (e.g. “Due to the weather conditions, today is a day-off for all. Stay at home and have a good time”).

Actually the system isn’t that complex. Basically all it needs to do is to enable administrator pick a group of users, enter the message and send it through the SMS gateway. The tricky things start from “pick a group of users”. We want this to be as flexible as possible so we could use this system not only for university, but any other organization.

University structure

This is obvious to anyone who studied at the university in Ukraine, Russia and former USSR, but I’m not sure the structure is the same abroad. So we have the university. There are faculties (e.g. Computer Science, Philology etc). These faculties have specialties. For example, Computer Science faculty has 2 specialties – “Intellectual Systems of Decision-Making” (mine) and “Computer Engineering”. (For those interested about the difference, first one deals more with AI technologies while the latter – with system programming, networks etc).

Next level is “course”. We call it so, but actually that is the year of study. I know, there are special words for the 1st year students, for the 2nd etc. Here we just say “I’m on the first course”. That means “I’m studying the first year”.

All students that study the same specialty and are on the same course are called “Stream”. This is literal translation and I’m sure there is some more correct term. I’d be thankful if someone posts it in comments.

There are 2-4 groups in the “stream”. In our university they are names as follows: 101, 102, 103 etc. First number is course. In this case it is the first one. Second number is the faculty code. 0 is for computer science. And the third number is the group number. Thus 102 is the second group of first-year students studying Computer Science. I realize that not all universities name groups like this, so we don’t want to stick to such naming in our product.

Now let’s go through the tutors and staff. There is a rector of a university. There are deans for every faculty. And all tutors are grouped by departments. Usually, departments relate to the faculty, but that’s not a rule. For example, on our faculty we have Department of Higher Mathematics, Department of Intellectual systems ans some others. One tutor usually belongs to one department.

In addition, there are different clubs for students like our “Geeks’ Club”, translators’ “Pickwick Club” etc. Some of these clubs (like ours) have departments (Web-development, OOP, Java, C++, Delphi, Administration etc).

We want to be able to filter users using all the above groups plus some more user-specific filters like age or gender.
Let’s go through the planned features now.

User perspective

First of all, user can log in. User should enter his phone number and password. We’ll possibly add additional security for administrators. If administrator logs in, he enters his phone and password, but then a dynamic password is sent to his phone. And he completes login procedure only after he enters this dynamic password. We’re not sure if we’ll implement this. Your comments are welcome!

Next, user can edit his profile. He’ll have the following fields there:

• Phone
• Email
• Password (and confirmation)
• Name, surname, patronymic
• Gender
• Birthday
• ICQ
• Faculty
• Course (1st year, 2nd year etc)
• Group
• Clubs user is member of
• Any tags user assigns to himself (e.g. “musician”)

Plus user should check the option “receive SMS”.

However, user can’t edit phone directly because we’ll have to confirm it. So instead of giving him the field in the profile editing form, we’d rather give him a button or a link which will bring him a from where he puts new phone number and password. After that a dynamic password is sent to his phone via SMS and he enters this dynamic password and phone is updated.

Finally, user may register. When registering, he enters nearly the same data as when editing profile, but there is a dynamic password sent to him in order to confirm the phone number.
All these screens are shown below.

User area screens

Group Administrator perspective

Group administrator role may be assigned to the club’s leader, to the group monitor (or it’s better to say headman? What sound more “English”), to the tutor or headmaster. Basically everyone who needs to send notifications will have this role.

So, this type of users can do the same as the simple user plus searching users, sending email notifications and viewing statistics.
Each group administrator will be limited to the groups he may view/notify. For example, headmaster can notify anyone. Tutor may notify all groups of students he tutors in. Group monitor may notify all students within his/her group.

Listing users and searching through them is done in the same screen. In the main part of the screen there is a list of users that are in the groups available to the group administrator. In the left side there is a “narrow search” panel which lists all filters that can be applied to the current set of users. Clicking the filter option (e.g. “Geeks’ Club”) lists all users that fall into the current filter conditions. And it also refreshes the filtering options. For example, if there is no girls in the “Geeks’ Club” then there is no point to show these option in the filter. This is harder to code, but it will bring excellent user experience.

In the right hand side there will be the “saved searches” panel. When you applied some searching criteria, you may save it with some label so you can quickly access this search in the future. Were going to create standard searches in addition to filtering to simplify the system’s usage.

This works as following. For example, you can view all Computer Faculty. But you need only girls from the Geeks’ Club. So you filter by gender and then by club. And save this search as “Girls-geeks” This immediately appears in the right “saved searches” panel.

These saved searched may be group-specific and user-specific. This basically means that when group admin saves search, he may select if he wants it to be private or he wants to share this search with other group administrators, who have access to the same groups as he does. We think, this will help users creating the searches that they really need. Sure, saved searched may be easily removed.

In the right side there will be also a “Send notification” panel. It will contain only textarea field and a “send” button. When you have your group ready, you type the message an click “send”. It asks for confirmation, displaying how much it would cost and sends it over.

Another page in the Group administrator’s perspective is statistics. Here he’ll see how much messages he sent during the last day/week/month/overall and how much did it cost.

As we progress with development, we may add some settings, that will be the third page then. Here’s the filtering screen:

Filter users screen

Statistics screen is pretty straightforward, so we’ll omit it here.

Administrator’s perspective

Administrator is almost god here He can manage users, assign rights to the group administrators, set limits of SMS count, view logs and overall statistics.
Users management screen will be nearly the same as filtering, with the only difference that when clicking the row with user’s you’ll see the profile screen with additional options:

• ban/unban
• delete
• phone editing does not require confirmation
• administrator of (group selection)
• notifications limit

Logs and statistics screens are quite simple too.

Use cases

After analyzing the above overview, we come up with the following use case diagram. It is pretty self-explanatory and written after the description above, so it is useful only as a summary.

SMS Notification Use Cases

Following the iterative development methodology, we should describe all usecases now, but I find this quite useless. After describing all usecases briefly, we should select 10% critical usecases and describe them in full. Full description includes the sequence of actions taken in the main success scenario and all alternative scenarios that may happen (e.g. DB error, connection failure, no users found etc). This is useful sometimes, but I think that for such simple application as this one, we ma skip this step either.

What is really useful about the iterative development at this stage is that it recommends picking 10% of the most critical usecases and start implementing them in full. By “critical” I usually mean those which may result in essential DB structure or application design changes. In our case there are 14 usecases.10% is 1.4 usecase. Let’s pick only one. The most critical usecase, that affects all the application design and DB structure is the user filtering. The success of an application depend on the stability and usability of this feature. So we should code it efficiently and then move to the other usecases.

I like this approach cause it is much more practical than designing the system from the interface. Changing interfaces and adopting them to core is much more simple and has less risk than doing vice versa.

So we decided to start with user filtering. The first thing we should create is the database structure. This will be covered in the tomorrow’s post.

I’d like to learn your opinion on all that. Maybe you can propose some better interface, or some nice filtering approach or just some idea for this. We’re open to all suggestions and comments! Thank you for reading my blog and following this project

Subscribe to RSS and stay tuned!

Liked the post? Bookmark it

Hide Sites

No related posts.

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

Most of the beginners and, sometimes, even more advanced programmers, want to develop everything from scratch because they want have control over the every aspect of their application. I entirely understand this tendency. When you learned how to program and you can code nearly anything you want (this relates more closely to scripting languages like php, perl, js etc), you start to do something global. Something that will change the world. This may be a new CMS, a new framework, new blog of e-commerce engine. And when you start this, you want to code it in the most efficient way, optimizing every little thing: every function, every SQL query. At the same time, you want to reuse the code you’re writing. So you tend to create more general solutions than you really need. And this slows down the performance. And again you go into optimization, limiting the possible uses to some extent.
Finally, if you finish your application, it may be faster or better than similar ones (however, usually it is the same or worse), but remember how much time you spent developing it. Yes, you’re proud of yourself – you’ve created your own DB abstraction layer, that handles SQL injections in a very smart way. You’ve also developed your own ORM engine, that goes nicely with your DB abstraction layer. It is quite likely, that you’ve already created your very own template engine and a nice JS library that makes animation very easy. Great job, my fellow programmer!

…but is it really brilliant?

Now let’s stop for a moment and look back. Why you’ve started developing all that? Say you wanted to create a brand new blogging engine, that is better than WordPress. You’ve spent several months (I can’t believe you’ve created nice DB abstraction, ORM and template engine in a week) to develop all that stack. And all you got is just another blog engine! Yes, it is cool and is capable of doing hundreds of things. You’ve even thought of the external API, so you can send SMS to be automatically published on your blog. But actually that’s just a blog!
Do you really think that the final result – blog engine was worth 2 months of the hard work and sleepless nights? If you answer “yes” and you haven’t got a feeling that something is wrong, then then you’re either mega-guru and develop only facebook- and google-scale projects or just a beginner who is still very proud of himself that he can code anything and you want to overemphasize this.
I think, every experienced developer was at that stage. I was there too. Moreover, I was there quite long and I regret of this.

So what is the framework?

By this time you may be quite bored and start thinking – what all that story has to deal with the framework. Actually the problem described above when you develop everything from scratch occurs when you don’t use any frameworks.
So what is the framework? Basically it is a set of libraries/classes, tied together that speed up the development of a certain type of applications. For example, MFC (Microsoft Foundation Classes), Qt, wxWidgets are frameworks that simplify the user interface development. It obvious that you should not draw 6 states of the button and change it on different events when it comes to placing the button on some form. You just use the ready-made class. But when it comes to the web-development, some developers think that they don’t need the ready-made (and well-tested!) DB abstraction layer, proven authorization classes. They want to develop it themselves. As a result, we often see low-quality and buggy applications. On the other hand, using frameworks does not necessarily gives you the excellent code, but it definitely helps you to get where you need much faster.

Use frameworks!

When you utilize good framework, you automatically get proven solutions in different spheres – DB connectivity, unit testing (most of frameworks provide tools for this or make it more simple), authentication, users and templates management. In addition, you also get a number of widgets, ready-made components for the problems you even don’t know about at the moment you start coding, but which usually come up during the development – caching, JS and CSS minimizing and publishing etc. Finally, you also get a bunch of extensions for a variety of tasks: RSS creation, CAPTCHA solutions, autocomplete widgets, treeview, drag&drop components to name a few.
The problem with framework usage for scripting languages is that they are quite simple and lots of developers don’t want to learn complex framework in order to achieve some simple task. And they are right… as long as their task is really simple. I think, “simple” is something that soesn’t require heavy DB usage, caching, user management, web-services integration and has very basic MVC implementation. That’s a simple homepage. All other projects should be developed with frameworks because that saves time and allows you to achieve better result.

Choosing the framework

But there is a little problem here What framework is “good”? I wrote about this in one of my previous posts where I explained why I chose Yii as a PHP framework for my project. Selecting wrong framework may result in project failure, so please refer to that post to see how I did that, maybe you’ll find that approach reasonable and join us in Yii community
And the last question I want to discuss here. The quality of code. I believe that using a framework with good design helps you to create better-structured applications that can be easily managed and supported. And the quality of code… I think this is up to programmer. It is definitely easier to create good application with properly designed framework just because you follow it’s patterns. However if you ignore the framework’s ideas and continue to create classes with static methods instead of simple functions, the framework is not very useful for you

When you should not use the frameworks

Frameworks are good, but you should clearly understand what are they doing and use them only when appropriate. As a rule, framework provides a set of generic tools that simplify creation of any project. Key work is any. These techniques give good result for a standard use. However when it comes to some specific things, especially if they are very demanding in terms of performance, it’s time to evaluate your tools from the point of view of this specific project.
Consider you have a framework designed for a web 2.0 applications. It works well for the most of the projects you create. However you’ve got to build an SMS portal. Unlike your usual applications, this doesn’t deal with HTTP a lot, it uses it’s own protocol. So 80-90% of your favourite framework’s tools will be useless here.
If you’re building very large application that will be working under the high load, you should evaluate your framework and either reconfigure it or refuse from using it at all. Most of the great websites like facebook, for example, don’t use standard frameworks, but in order to become “facebook”, you should gain popularity and using the framework for your first version ill bring you to the marketing and launch much faster and you’ll start earning money.
Similarly, if you’re building the business-card-like page, using the framework is a bit overkill

Summary

1. Use frameworks because they simplify your development, help getting better code and simplify documenting your solution (framework documentation is already written!)
2. Choose framework very carefully!
3. When solving non-trivial tasks and develop extremely large applications, re-evaluate your framework’s features and decide if it really worth using it there.

Disclaimer

1. All above is my own opinion, formed during the 5+ years of everyday web-development. Maybe this is not the absolute truth, but I believe it is somewhere near it
2. Example with SMS portal was for illustration only, I’ve never developed ones and don’t know which protocols are used there. I’d be thankful if someone of my readers clarifies this.

And what do you think about it? I’d be thankful if you share your thoughts in comments. Thanks!

Liked the post? Bookmark it

Hide Sites

No related posts.

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

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.

OOP is a great concept, it simplifies the programmer’s life, especially in the field of interface development. Nearly all modern web-interfaces use JS in some way – for field highlighting, validation, help etc. It’s OK when there are such simple things.
And now imagine, that we have a set of dialogue windows (HTML+CSS) for adding a comment, rating, sending to the friend. Each of these boxes has a number of functions – check if user is logged in(if not – show login form), send AJAX request, process response, show error/success messages, position the box on the page etc.

The problem

First idea I had about them is to use simple inheritance, create Box class, derive CommentBox, RatingBox and other classes, but it turned out, that jQuery (I used it there, because system is built using Yii framework, which uses jQuery for client-side coding) doesn’t support extending classes like, for example, ExtJS or YUI. Yes, it has $.extend() function, but it just copies the object, not actually extends class. Why it is not the same? Let’s look here:

Normally (in ExtJS, for example) when writing:

I expect, that if I do:

I should get an alert window. However, this is not true for jQuery. It just copies everything and we get some messed things. So I gave this up and followed another pattern.

The solution

Box object became container for all boxes. I took care of messaging, determining if user is logged, and all other routines. It also serves as a factory, because all clicking icons go to the showHide method and it has to determine, which box to show and create this inner object.
And this inner object takes care of the box-specific logic. If it needs some common info, for example, the ID of the product it is called for, it calls the Box method (see LowCoupling GRASP principle here ). So in the Box I have:

So instead of inheritance I implemented aggregation (Box aggregates CommmentObject, Favourite object etc).

Everything goes well until you want to to attach some method of current object as a handler to some event. For example:

Right? Wrong! Because when submit event occurs, jQuery will call the onSubmit method, but this will refer to the form, not to the Box object! However, it is logical to put processing of the form into the same object. In ExtJS and YUI you can pass the scope parameter for every callback function, so you can control the “this” variable in the callback call. jQuery doesn’t allow this. I used the following workaround:

If you need the object, that triggered an event, just pass “this” there:

Having these 2 tricks you can use OOP approach to designing reusable interface components in a handy modern way.

Back to inheritance

Since I discovered the problem with inheritance, I want to develop a plugin, that fixes this, that will provide nice class inheritance model to take jQuery a step ahead. I was going to digg the ExtJS’s Ext.extend() code and find out how this is done correctly, but while preparing an article, I found this material, which is actually a guide for creation of such plugin: http://phrogz.net/JS/Classes/OOPinJS2.html. Unfortunately, I don’t have time for this now, but I plan to do this in the nearest future. If someone does this earlier, please let me know

Links

• ExtJS – a component, interface-oriented JS framework
• YUI – Yahoo library for the user interface. ExtJS was derived from it long ago. They are similar in extending and event processing (the “scope” I mentioned initially appeared in YUI)
• jQuery – a lightweight VERY popular JS framework with an easily extensible structure, but lacks OOP techniques!

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.

Adapter design pattern

Template Method

You see, using adapter is more like implementing the interface, while using Template Method is about implementing the parts of algorithm differently. So Adapter is used when we need all modules/components to response to the same API. At the same time, we use Template Method when we have some general process, which differs in minor details, which we implement in the derived classes.

For example, we should use Adapter pattern for the DB abstraction layer and TemplateMethod pattern for the calculation of table’s volume (see “What is OOP post”, I showed this example there)

Further reading

• Adapter pattern
• Template Method pattern

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.