underdevelopment

Sometimes in applications you will have certain user settings that you want to apply, even when the user is not logged in. Take for instance these examples:

• “welcome back <name>” msg on return.
• You have a portal type page where the user can control what content is shown where
• You want to track where the user was when he last visited the site, perhaps to offer him the option to return to there.

I recently needed some functionality like that. So I’ve created a object that can help me with that.

I thought about it for a moment and created a singleton settings object for me to call upon to set and retrieve certain settings. Now I have to warn you that there is a small problem with singletons, if you use unit testing it can be difficult to control the behaviour of singletons over multiple tests. So be wary of this when you are running unit tests.

I also wrap all data in a separate array. This isn’t really necessary, but it makes handling the data a lot easier. If you wanted you could also add some sort of encryption to the cookie data so that users couldn’t easily tamper with it.

admin PHP, software development design patterns, object oriented programming, PHP, singleton, techniques

First you will have to excuse me for last week, while it is my intention to write at least one blog post a week, real life and more specifically a current project at my job have had me tied up quite a bit I’m afraid.

Also in the interested of actually writing about something people would want to read, I am paying special attention to the popularity of my blog posts. Since at the moment I have only 4 posts and about roughly the same amount of visitors, I can hardly make any real conclusions from that data. However even with numbers as low as those, it seems my blog post about object oriented programming is by far the most popular. This could be skewed for many reasons, but for the moment I will assume it is true. If any of the four people whom read this blog would like me to address some other topic, then please do use the comments and I will see what I can tell about the subject.

Now with all that said, it will come to no surprise that I will try to explain a little bit about object oriented programming. Specifically, as the title already betrays, about encapsulation and the command pattern. Now I know I already briefly touched on that topic in my previous blog about OOP and patterns, but I just like it and it is my blog.

So what is encapsulation, and why should you care?

Encapsulation is, as the word describes, the idea that functionality and data should be encapsulated within its own domain. This, at least in my eyes, is the single most important and single most beneficial aspect of object oriented programming. In a way it even defines what object oriented actually is.
A object is a representation of a distinct entity of your program, which encapsulates its behaviour. Thereby abstracting the functionality and making it easier to work with and think about.

Now that is all well and fine, but why would I want to encapsulate, you ask,? Well depending on your level of experience with existing code the answer should already be painfully clear. Just think back about that project that was built years ago, which kept getting more feature requests until the initial functional design in no way represented the project as it is now. Such projects often suffer from bad encapsulation, different parts that intertwine way too much with each other. Making it expensive in time to add/remove or even modify features.

That is exactly what encapsulation fights. By correctly encapsulating behaviour you guarantee that none of the encapsulated functionality is touched upon elsewhere in the project. You effectively limit the domain it has effect upon.

Many if not all design patterns embrace the idea of encapsulation but I think the command pattern does so in the most direct way. The command pattern as I explained in a previous blog post encapsulates a piece of functionality exposing only a common method to call it, this is useful in many ways. Think for instance about “actions” that need to be executed or as a specific example the image manipulations from my previous blog. I could have put knowledge about those things in the object that handled the images as collection. That however would have meant that that object now, not only has to know about the images, but also about how to manipulate them. That may sound minor, but in reality that would in fact give a single object two responsibilities. Now while I do not have direct proof, I can guarantee you that however elegant it might initially be written over time the object would get encumbered with even more functionality for manipulating images.

However if the manipulation of images is in fact fully encapsulated within a separate object that bears the responsibility to do just that one action, we force ourselves to keep that functionality within that object. Meaning that however much we might change the way those images are manipulated we will never need to touch the object that controls the collection of images. We could for instance easily switch from using GDlib to libMagick. The only thing we would need to do is modify the command objects and perhaps their parent object which might contain shared functionality.

You might even imagine we could keep both these versions and detect up-front what modules are available to us and choose which set of command objects to use, depending on that. If we had not used the command pattern it would not be unthinkable that this choice would also have ended up in the object that initially only held the images, thus creating the start of the wild growth that would eventually lead to a super sized object that might hold half of the project functionality.

-edit-

Disabled comments because I was only getting spam. If you want to comment just do so on another article and add that it was actually for this one and i’ll move it or something.

admin PHP command pattern, design patterns, object oriented programming

About two years ago I wrote one of my first “true” object oriented php projects. I say “true”, because before that I had dabbled and played with OO, but never had I had a REAL project with it. Well “real” project is perhaps overstating it a bit, but it ended up with about 2000 lines of code, which is the borderline where something becomes a project in my book. The rest is just proof of concept or small scripts.

To start with some honesty, if I look at it now, and I am looking at it now, a lot of it is crap. But the one thing that started this project is still a nice implementation and also the subject of today’s blog post.

Many of the projects I have done in the past have started with a theoretical problem and the problem with theoretical problems is that they are not really problems; not in a way as for example building a bridge is a problem. So I invented a program idea that would present me with just that problem. The problem that day was that I could not seem to figure out how to do a plugin architecture. Now to some, this may sound simple, but at that time I simply couldn’t seem to figure it out.

So I started this project called libPhoto. LibPhoto was meant to become a generic back-end library you could use to manipulate images via an easy interface that abstracted complex modifications to the image. Ok ok, I admit, I also was interested in computer graphic algorithms at the time. But that’s for a different day.

Now one of the key aspects of this libPhoto would be that each modification would be a “plugin” for the library, so that it could easily be extended. The other key aspect was that libPhoto didn’t really needed to understand these modifications, it would only understand “versions” of an image. When talking to libPhoto you could tell him what a specific “version” of an image was called and what attributes it had.
Here some code to show how that looked in practice.

$libphoto = new libPhoto();

$resize = $libphoto->newMutator(‘resize’);
$resize->config(array(‘width’ => 200, ‘width’ => 200, ‘keepAspect’ => false));

$dropshadow = $libphoto->newMutator(‘dropshadow’);
$dropshadow->config(‘gausSize’ => 3, ‘offset’ => 15);

$thumb = $libphoto->newImageVersion(‘thumb’);
$thumb->addMutator($resize);
$thumb->addMutator($dropshadow);
$libphoto->setImageVersion($thumb);

$imageVersions = $libphoto->processFile(‘/some/image/file’);

Now the nice thing about the above, is that libPhoto, the codebase itself, has no idea how mutators worked, nor does it care. What you are seeing above is the end result of such buzzword patterns as the factory method pattern and command pattern. Or at the very least, I like to think it does. And as to explain why I think it does, i’ll go over what is happening behind this code.

$libphoto = new libPhoto();

Well, pretty obvious, it instantiates the libPhoto class into an object, which then does all kinds of stuff behind the scene like scanning to see what Mutators it has.

$resize = $libphoto->newMutator('resize');
$resize->config(array('width' => 200, 'width' => 200, 'keepAspect' => false));

Now here we can really begin. When requesting a new mutator object from libPhoto, libphoto will check if it actually exists and if it does, will instantiate it for you and supply it with some default configuration options and will ask it about some small details like if the current php installation contains the requirements to run that mutator. Which in most cases equated to “does it have GDlib”. After it prepared it for the harsh world outside, it returns it back to the code we are reading. At which point we could supply it with some extra configuration options. We could have asked it for those configuration options, but since I wrote the damn thing, I should know what its config options are.

Now I could of course have trusted on the puppy dog eyes of developers everywhere to implement some default methods, but in a more sane approach I actually implemented an interface to which all mutators needed to comply. Furthermore all Mutators extended from a baseMutator which already implemented various default methods like reading the config options and storing them as private variables.

So in the end your average mutator looked roughly like this

/**
* This mutation makes the image greyscaled
*/
class mutatorResize extends baseMutator {

private $ConfigOptions = array(
‘width’ => ‘int’,
‘height’ => ‘int’,
‘keepAspect’ => ‘bool’
);
/**
* This turns the image grey.
*
* @param gd image resource $image
* @return gd image resource
*/
function process($image) {
// … snip …

return $image;
}
}

As you can see, it really only defines some options that the process will use to do its job and after that only define a process which does the job.
All the tedious stuff like reading those config options or explaining them to the underlying system where all already generically defined in the baseMutator.

$thumb = $libphoto->newImageVersion('thumb');
$thumb->addMutator($resize);
$thumb->addMutator($dropshadow);
$libphoto->setImageVersion($thumb);

$imageVersions = $libphoto->processFile(‘/some/image/file’);

Now the first line is more of the same as the previous one with the mutators. It instantiates an new imageVersion object which get’s a few default config options before being passed along. Then you add some Mutator objects, and basically tell libPhoto there is an new image version. After having done all that we tell libPhoto to process an image file.

LibPhoto will then iterate over all the different image versions it has and tell them to do their thing. The imageVersion object will open the imagefile and create a GDimage resource and iterate over its mutators and pass them the file and tell them to do their thing.

The mutators will gladly accept the GDimage resource, do their magic with it, and pass it back. In the end the imageVersion writes the GDimage resource back as an image file and passes that file location back to libPhoto.

This is I think a perfect example of encapsulation and the command pattern. None of the objects even remotely care what the other is doing but just know how to tell it to do its “thing”.

I hope you enjoyed reading a bit about this, i know it’s all pretty basic stuff but i hope i’ll be able to expand into something a bit more complex when the time comes.

-edit-

Disabled comments because I was only getting spam. If you want to comment just do so on another article and add that it was actually for this one and i’ll move it or something.

admin PHP command pattern, design patterns, factory method pattern, libphoto, object oriented programming