Using Objects to Create an Application

Intended Audience

Overview

Prerequisites

Background

Why OO can work with PHP

The Task

– Step 1: Define the classes
– Step 2: Define attributes and methods for the classes

– Step 3: Implementation issues

– Step 4: Create a class diagram
Some OO Tips and Commandments

Next Time
About the Author

Intended Audience

This tutorial is intended for readers interested in Object Oriented Design.
Knowledge of PHP concepts is not necessary, but knowledge of PHP’s OO syntax,
and of working with PHP’s mysql functions and objects, is assumed.

Overview

This tutorial is the second in a series dealing with using objects to create
an application — building the application up from smaller parts — and teaching
important software engineering and design concepts that will be useful writing
not only in PHP, but in other languages as well.

The specific project assigned is creating an online posting system. This article
concentrates on the design stage of the project.

Prerequisites

Knowledge of OO concepts, and a limited understanding of software design.

Last time we showed a small example of the benefits of using objects to abstract
details that the application programmer would like to avoid dealing with, and
also to abstract out business logic.

This time we will actually see the power of using objects as components of an
application. Objects are connected together, with each object serving a particular
functionality of the program.

Background

OO programming is one of the greatest innovations in programming since the invention
of the compiler. Objects allow a programmer to break details into smaller parts,
to encapsulate data, and (when written in correct OO) to allow objects in the
program to model objects in real life!

It gets even better. As you will see here and in the next article, OO greatly
helps in the design phase of project development. It is possible to model the
flow of execution, and the entire composition of an application, using diagrams
like class diagrams and sequence diagrams.

Breaking an application down into objects — physical parts — is far superior
to breaking it down into processes, (called “functional decomposition”).

Another big benefit of classes is the creation of class libraries. Class libraries
have all the trimmings of function libraries, and so much more! Imagine going
to a library and “pulling off the shelf” a class called Member,
that would handle storage and retrieval for you without you having to worry
about database details at all. That will soon be a reality, as I am currently
coding a library called PHPZeus, (and another library called JavaZeus, for Java),
which works like a message board system. When building an application, you can
literally go to the Messaging package, pull out a message class, then a Thread
class, and put your message board together!

Why OO can work with PHP

Despite the fact that PHP OO pales in comparison to that of Java, and the PHP
runtime system’s handling of objects of woefully inefficient, objects can and
have been used to build applications. (Just check out my site http://www.enetexperience.com
where almost all of the dynamic and interactive content is provided by OO PHPZeus.)
You can use OO abstraction to abstract out business logic. Furthermore, according
to the Zend2 pdf forecast many object problems will be corrected by the new
runtime (with the exception of multiple inheritance, which I believe complicates
coding and design). Instead of multiple inheritance, aggregations and composition
should be used, delegating the functionality of an object into another object.
The main benefit that the Zend Engine 2 will bring is that PHP object variables
will be handles, not physical objects, similar to the way that a Java object
variable is a pointer to the location on the heap where the object is stored.
Finally, private fields will make PHP’s OO system more complete.

The Task

Our assigned task was to create an online posting system. Of course the actual
requirements of the assignment were left out last time (in Part One). Now we
have some concrete specifications that we need to follow.

1. We must maintain an account system of members. There will be two types
   of members, normal users and administrators. Members will contain information
   such as email, username, UID, and password. Admins, in addition to all the
   features of a member will contain a position and employee number.
   
2. Administrators must be able to add new news topics to the website.
   
3. Administrator must be able to edit or remove topics, edit or remove other
   members, add new members, and award admin powers to another user.
   
4. Users must be able to post comments to a news article posted by an admin.
   
5. Each member will have a list of members or buddies.
   
6. Members must be able to send messages to one another.
   
7. Messages will consist of a subject, a message body, a date, and a posting
   member.
   
8. News messages will be messages that also contain a list of comments to
   that item.
   
9. The message list must be able to store messages in order, by the date
   on which they were posted.
   

Now that we have our program requirements we have to decide how were going to
design this thing. The majority of software development time is taken in designing
(and testing) the software. Only 20% or so is spent on actual coding. Writing
code is actually quite unimportant in the overall scheme of things. Design is
so much more important because without it is impossible to make a decent program.
Let me just say that again to make sure it sinks in: It is IMPOSSIBLE to make
a decent program without first making a decent design.

This article focuses on the design stage of the project. No code this time.
Since there is no code you could theoretically take the design we make here
and write it in any other language (such as my favorite, Java). However, since
we are designing a PHP application our design must take into account both the
limitations and the features of PHP.

Step 1: Define the classes

First we want to define our objects: the objects we are actually going to use
in our program. Then we should break our classes into categories. These categories
describe the functionality of our classes. There are two category systems that
we can use. OO level categories, that give description of our classes from an
object perspective. And application level, that describe what role our classes
will play in the application.

Here are the OO categories:

Actor Classes

Classes that represent people. Actor classes have their own attributes as well
as the ability to perform actions.

Data Classes

Classes that represent data. They have attributes, but usually do not have the
ability to perform actions.

Action Classes

Classes that perform actions. Can perform computation as well as act on other
objects. More likely than not these classes won’t have specific attributes.
Lots of business logic can be contained here.

Collection Classes

Objects that hold other objects.

So now that we defined the categories of classes, we need to define exactly
what classes we need to use. The simplest way to go about doing this, in my
opinion, is to step through our criteria one by one, determine what classes
we need, and add them to the list. We could group our classes into the four
categories while we step through the criteria or we could do it after. I choose
to do it after.

Let’s examine our criteria.

1. We must maintain an account system of members. There will be two types
   of members, normal users and administrators.

   Right here we potentially have two classes. We will definitely have a Member
   class (we coded this last time). And we might have an Administrator class
   that extends member.

2. Administrators must be able to new news topics to the website.

   This requires that we have some method of posting messages to the website.
   We could either have our form processing script handle this, or have a method
   in our Admin class. Regardless of which way we choose to implement posting,
   we requires a Message class.

3. Administrator must be able to edit or remove topics, edit or remove other
   members, add new members, and award admin powers to another user.

   No new classes here.

4. Users must be able to post comments to a news article posted by an admin.

   More posting. A post processing class seems to be in order since we’ve seen
   posting in three different elements of the criteria. Also, since there is
   a difference between user posted messages and news articles, we should have
   two different classes to represent them. We could create a generic Message
   class, and have admin posted article extend from that.

5. Each member will have a list of members or buddies.

   We need a data structure to hold member objects.

6. Members must be able to send messages to one another.

   Take your pick. Form a processing class, or method into the message or member
   class. Previously messages were posted to the public, but now we want to
   enable messages to be sent by one person to one other person. The sender
   attribute is still present, but now we must also specify a recipient Differing
   attributes exist, so the creation of a subclass of Message is warranted
   here.

7. Messages will consist of a subject, a message body, a date, and a posting
   member.

   Nothing new here.

8. News messages will be messages that also contain a list of comments to
   that item.

   We need a data structure to store messages.

9. The message list must be able to store messages in order by the date
   in which they were posted.
   

For now all we’re doing is defining classes. The methods for defining
them do not concern us.
So now we have stepped through our criteria, and defined some classes we need
to define. So now lets put them into our four categories.

Actor Classes:

Member
Administrator

Data Classes:

Message
News Item

Private Message

Action Classes:

Form Processor
User Manager
Admin Manager

Message Manager

Collection Classes:

Buddy List
Comment List

Notice that simply by going through our criteria we were able to come up with
a list of 11 possible classes. We may end up adding more classes, or subtracting
some classes from this list, but at least we now we have a rough estimate of
the classes we need.

Step 2: Define attributes and methods for the classes

Our next step is to define what attributes and methods we need for our classes.
At this point in our design we will still not take into account that this is
a PHP application, so this next section is still language independent.

Member:

UID
E-mail
Username
Password
Buddy List (instance of Buddylist)

Retrieve() for retrieving data from our data store
Update() for storing data in our data store
Get/Set methods

Administrator
Extends Member

Position
Employee Number

Retrieve() for retrieving data from our data store, must override here since
this class has more data that we have to store
Update() for storing data in our data store
Get/Set methods only for new attributes

Message
Subject
Message Body
Date
Posting Member (instance of Member)

Get/Set methods
Send();

News Message extends Message
Comment List

Get/Set Poster
Send()

Private Message extends Message
Sender (instance of Member)

Recipient (instance of Member)

Get/Set Methods

Form Processor, User Manager, Admin Manager, and Message Manager.
We shall worry about the details of these classes later.

Buddy List
Buddies[]

Add()
Get()
Remove();

Comment List
Comments[]

Add()
Get()
Remove()

Through examining our criteria we have created our classes and have brainstormed
some essential methods that our classes must have.

Step 3: Implementation issues

We now need to consider actual implementation, The we will create a class diagram
representing the relationships between our classes. This is still largely language
independent, but as you will see we will begin to take into account that this
is a PHP program.

We know that Member and its children, and Message and its children, each have
update() and retrieve() methods for retrieving data from our data store. Since
this is a PHP application we can assume for now that the data store is a mysql
database, but the data store could be anything, even a flat file storage mechanism.
(Since there are different types of data store we should really have a processor
class so that our objects don’t care what the data store is, but that would
make this project overly complex so we wont worry about that here. If we were
concerned about this, we would pass our queries to the processor to handle the
details.)

One thing we do need to be concerned with is the login info about the database.
This is accomplished by the settings class (dealt with in Part One of this series).
That way, if the login and access data were to suddenly change all we would
have to do is modify the settings file, rather than modify all our classes.

The next implementation issue that we have to deal with is the presentation
of the lists (buddylist, comment list.) Here the fact that this is a PHP application
will greatly effect the implementation of this feature. If this were a Java
program, one would either implement a linked list class, or return an enumeration
or vector of elements, presumably wrapping that Enumeration or Vector in a wrapper
class, to handle business logic on the elements. The simplest method to get
this to work in PHP is to return an array of member objects (or message objects),
but in my personal opinion returning a plain old array isn’t good OO abstraction.
So I would create a class called BuddyList, which encapsulates an array. When
you call add() it adds a new buddy to the array, and remove() removes a member
from the list. The same will be done with Comment List.

Finally the processor. We need at least one processor to serve as the bridge
between the static HTML interface and the actual system. This class will instantiate
the objects necessary to complete the task. You may want to use abstraction,
abstracting out specific functionality like data store manipulation into another
processor class, an instance of which is created by the main processor class.

Step 4: Create a class diagram

Now all we need to do before finishing our object design is describe the relationship
between our classes, and then draw a simple class diagram, which will provide
a visual representation of our classes and the relationships between them. Class
diagrams are just one of the design mechanisms used in industry to model the
objects that make up an application.

This is a standard UML class diagram. I modeled the objects in our system. The
arrows indicate inheritance while the lines with diamonds indicate aggregations.

Some OO Tips and Commandments

If two classes implement largely the same functionality, and have largely the
same attributes, make one class a subclass of the other.

Do not think of objects as function libraries. Sure some classes implement static
methods, but those are classes, not objects. Objects are supposed to represent
physical things. Objects are people, things, or processors that operate on other
objects, but not just collections of functions.

Keep instantiable classes simple. Use abstract classes to contain all methods
that your class hierarchy will contain, and have the classes that you will instantiate
extend off from the abstract class. PHP doesn’t have an abstract construct,
but you could easily implement one by making a call to die (“Attempting to instantiate
abstract class”) inside your constructor.

To keep things simple, don’t include too much functionality inside a single
class. Instead use compositions. Objects, just like the application as a whole,
should be comprised of smaller parts. Each object should have specific functionality.
Place dissimilar functionality into other classes, and instantiate those classes
from your class. Classes can instantiate classes, something that professional
OO programmers know and utilize.

Develop class libraries, so that you may reuse such classes in later projects.
Your projects can either use these classes directly, or your project can have
subclasses that extend from classes in the library. This is the way the Java
API is set up. My PHPZeus project is also a class library that programmers will
be able to use in their projects.

Consider a class hierarchy, having all classes descend from a common super class.
This technique really applies to languages like PHP, Perl, or C++. PHPZeus has
all classes extend from class ZeusMethods, but JavaZeus obviously doesn’t because
all classes in Java already extend from a common super class, java.lang.Object.

Next Time

Next time we will model the actual flow of execution.In doing so we may find
we need to modify our classes. The execution model will hopefully show more
clearly how classes and objects interact and function within an application.

About the Author

Michael Johnson is currently an undergraduate student at the Georgia Institute
of Technology, pursuing a degree in Computer Science. He has programmed in Java,
C, PHP, and Pascal. Michael Johnson is currently the telecommunications chair
of the Georgia Tech chapter of the National Society of Black Engineers. The
website of that chapter is located at http://www.gtsbe.org.
He is currently starting up a web company called Extremistnet, http://www.enetexperience.com
that among other things develops applications written in PHP and Java.

2 comments to “Using Objects to Create an Application”