Developing useful application level PHP components - PHP Classes blog

By Manuel Lemos
manuellemos.net
<email contact>

Hello,

This month I would like to talk to you about methods to develop PHP applications and components in a way they can be useful and raise the interest of more other developers and members of the PHP community.

Over time, many PHP developers have submitted their packages to the PHPClasses site. The complexity of the packages can vary from the very simple to the very complex.

Regardless of the packages complexity, what matters for most users is whether the packages can perform useful tasks that benefit their applications.

Most of the packages made available are what I call utility classes. This means that they can perform useful tasks, but alone they do not implement application level functionality.

For instance, there are packages that can send e-mail messages, but alone they do not provide a complete solution that performs all the tasks necessary to manage newsletters, like taking care of the subscribe and unsubscribe process, handling bounced messages, composing personalized newsletters, etc..

To be fair there are indeed a few packages that provide this application level component functionality that I am talking about. However, those represent a very small minority of the packages published in the PHPClasses site. Therefore, my message today is to encourage all the developers that would like to contribute with their own application level components.

Note that I am not talking frameworks or extensive packages. Currently, there seems to be a "framework fever" in the PHP community. Many individual developers and reputed companies have released their own frameworks and are pushing them as the ultimate solutions for all the PHP development problems.

I am sure that those frameworks can be useful to their developer communities, but that is not what I am talking about. Most frameworks are sets of classes bundled together with some interdependency, but alone they also do not provide autonomous application level functionality.

Good application level components are reusable to the point of being easily integrated in different applications developed by the same or different developers.

But how can you write good reusable application level components?

I am sure that some of you are experienced developers and already have your own methods to develop your application level components.

On the other hand, I assume there are other developers that are not sure what are the best practices to develop application level components and would like some advice.

This message is exactly about that, providing advice. I am not going to tell what are the best practices that everybody agrees. I am just sharing my opinions about what are the best practices based on my experience.

I work with PHP since 1997, in the PHP 2 beta days. In 1999, PHP 3 introduced OOP support. That was when the PHPClasses site was born. Despite some people consider that PHP only became really an Object Oriented language with PHP 5, the OOP support introduced with PHP 3 made it possible to properly encapsulate simple or complex functionality in PHP classes of objects.

Since the beginning of the PHPClasses site, I felt the need to encapsulate the different situations that the site need handle. A class is the most obvious data structure that PHP provides to encapsulate application level functionality. The PHPClasses site code is mostly made of a tens of classes that implement many application level components.

In the beginning I did not have a good notion of what mattered in the development of these components. Over time I realized that they need to have a well thought API, so the same components could be reused in other sites developed by myself or other developers.

The best way to develop reusable application level components is to write them in a way that they provide the same consistent API. This makes the components easier to understand, easier to build and easier to learn by other developers that can reuse my components.

Over time I have developed and refined my own methodology to develop application level components with a consistent API. However, only last year I have started producing some documentation about my methodology.

In early 2005 I was invited by a local university to give a special class as part of an IT post-graduate course about PHP Web development methods and practices. PHP did not use to be taken very seriously by the academic world. So I was gladly surprised by this invitation.

The slides of this special class are available here. Unfortunately they are only available in Portuguese because the class was for Brazilian post-graduate students.

http://www.meta-language.net/metastorage/MetodologiaDeDesenv ...

That was when I decided to give a more official name to my own Web development methodology: Use Case mapping. Use Case mapping is a systematic methodology that defines how to depart from UML use case diagrams to implement the application use cases as PHP classes of objects.

For those that are not familiar with these concepts, use cases are the different situations that a software system must handle. Use cases are often referred to as the pages or screens, like for instance: the login page, the subscribe page, the article submission page, etc..

UML is a visual language that provides several types of artifacts in the form of graphical diagrams that represent different aspects of a software system. The use case diagram is one of those artifacts that is used to represent the different use cases that a software system must handle. Here is an example image of an use case diagram:

http://www.meta-language.net/metanews-use-cases.gif

If you want to study more about UML and use cases, I recommend these two books that I have reviewed in the past. They are not specific about PHP or even Web applications, but they are very good to introduce you to these subjects.

http://www.phpclasses.org/reviews/id/020165783X.html

http://www.phpclasses.org/reviews/id/0201309815.html

The Use Case mapping methodology defines how to implement each use case by writing classes of objects that implement a compact MVC approach to separate aspects that concern the application logic processing (Controller), application output (View) and application information access and manipulation (Model).

There is a lot more to say about this methodology, so I will not extend myself about this subject here. But I can tell you where to obtain more information about this.

I have been working on an example application to help the developers that want to use Metastorage. Metastorage is a tool that I have been developing since 2002 to accelerate PHP Web development. In case you do not know it, Metastorage is a productivity tool that generates PHP classes of persistent objects that perform Object-relational mapping.

http://www.meta-language.net/metastorage.html

This week I finally released the Metastorage example application I have been working one. It is a simple news publishing system that I named Metanews. It is available as part of the Metastorage distribution and has an online demo to let everybody see it in action:

http://www.meta-language.net/metanews.html

Since I also used Use Case mapping, I included detailed explanations about this methodology in Metanews documentation.

This documentation is written in English so everybody can understand. I am not a native English writer, but I hope it is clear enough for you to understand and adopt if you agree that this is a good PHP development methodology.

http://www.meta-language.net/metastorage-example.html

This concludes this month newsletter. It was a bit long, but I hope it was worth the time I spent writing and you spent reading it.

With this suggestion of a methodology to develop PHP applications, I hope in the future we can see more and more application level components being shared by you in the PHPClasses site.

As usual, I welcome your feedback regarding what I wrote, doubts and questions, write articles about the subject, how to make the document clearer, including any spelling and grammar improvement suggestions. Please send your comments to info@phpclasses.org .

Regards,
Manuel Lemos