Design Patterns

PHP is a very powerful platform if used accordingly. Back when I was in college, I certainly thought of using PHP as my main weapon for development and considered it as the backbone of my career even before graduating college. My PHP Skills are still within me but it certainly not the primary choice. But a good look at the remarkable existing framework it had and I’m back on track in investing time using it. 🙂 CodeIgniter is a PHP MVC Framework that simplified development by introducing pre-built APIs and Helpers for developer so lessen the development time, as well as give a familiar pattern to ease the development process. Here is a quick video tutorial on CodeIgniter from their website.

In my efforts to learn the new stuff, I used the first IDE I ever used: Dreamweaver!

Put it on your htdocs folder (for XAMPP) – with a little googling, you can actually change the hosting folder to any specific folder you want.

Here’s a sample Source code POS System I extended that uses CodeIgniter:

Notice the structure of the folders. This is how it made it easy for developers. All components have its own sub folders with a very sensible naming on each (Views will be on the views folder, Controllers are on controller folder, etc.).

I deployed this Application on my own domain, feel free to check it out: POSv1 (username: sampledemo / password: sampledemo). This is actually my efforts to put a POS system in one of our Mini Stores – although, this is a bit an overhead since I can just buy us an actual POS system, its fun learning codeigniter and know its potentials.

I’ll post more tutorials on these on later. Feel free to checkout the POS application above and tell me your feedbacks about it!

The Observer Pattern has been one of the most widely used design pattern in Software Development. If not most, many use the pattern for their development to call different independent modules to do processes after the initial action from another module. Certain scenarios like, a display table was updated after an insert call, a window resize after a clicked of a button.

JEE6 introduced a more easy way of using the observer pattern.

Assuming that you have a ManagedBean, with a register transaction method.

Observe this:

Event<?> will be the one responsible for storing entity or object to be observed.

A fire method is called passing the entity. (memberEventSrc.fire(newMember));

Once the fire event method is called, it will search for all ManagedBean observing this entity.

Observer this:

@Observe annotation is used for the final Member class in the method, this is our flag for the method call

This is located on the ManagedBean – We need a POJO that is class loaded for this process.

The MessageProducerList class is also a ManagedBean that is called after a transaction is made. The fire event from the MemberRegistration ManagedBean will call the method (on the screenshot) to load all the members. These list of members is then loaded to the JSF Page.

The Factory Method as defined: “Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses“. The main point of using this design pattern is to use an interface to hide the class and use an abstract factory method (from an inherited abstract or concrete class) to create composition of the actual class.

Basically, I created a schedule object that will generate a family schedule. We have an interface class to impose the factory method. Then an Abstract Class to hide the actual initialization of the derived class.

if looked carefully. We can see that once we initialize the Concrete Class – it calls the Abstract Class constructor that defers the process of constructing to the createSchedule() method. This brings more security to our code in terms of the creation of the concrete class, we can use this pattern to create objects that has commonality in terms of its composition (common interface / abstract class).

By definition, “Separate the construction of a complex object from its representation so that the same construction process can create different representations.” There are actually a lot of builder pattern available. I found that very optimize pattern by Joshua Bloch in his book Effective Java 2nd edition. The sample I created is based from the most basic builder design pattern.

The code basically showcase a simple vehicle builder classes that is used by a shop class to build the actual cars. It seems that the Shop is actually doing the building process yet the only thing it does is that it delegates the responsibility of building the objects in a builder class.

By Definition, Abstract Factory is “Provide an interface for creating families of related or dependent objects without specifying their concrete classes.“. This simply means that this design pattern is made to hide the actual derived class and create a new layer (or wrapper) that will create the actual instance of this classes. The groupings of classes will be based on their relationship and commonality among its features.

I create a Java code that will showcase the design patterns benefit. The example I made is based on a real world scenario where person types are created for the factory business that needs them.

Checking at the code. The PeopleFactory is an abstract “wrapper” class created to host the creation of Person Objects. As seen, the PeopleFactory provides the layer of security as it hides the actual class implementation / initialization.

My Cent: Abstract Factory do protect the actual implementation / derived class by encapsulating from the other layers of the application. Yet It does have one disadvantage in terms of flexibility: Its made of an abstract class. As every developer should know, abstract class are also extensions of derived class – inheritance of a derived class. OOP only supports single inheritance and that makes the actual factory class not flexible enough.

What do you think is the best replacement for an Abstract class in this case?