underdevelopment

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

Now regexes are a wonderful thing. Personally i can’t get enough of them. they are terse, compact, to-the-point and have a extremely high geek value. Below I will show a example of how you can use simple regular expression rules to accomplish a non-trivial task.

shortening a text

Often we will want to show a short excerpt of a full text, think for instance about articles and what not. A common but ugly way to do this is via substr(). A much more elegant way is via a regular expression.

A easy way to do this is via the following one liner.

preg_replace('/(.{1,250}\.)\s.*/ms','\1', $text );

What this does is select all text, with a sub selection that selects the greatest range of all characters between 1 and 250 ending on a dot. Then it replaces the text with that sub-selection. Resulting in a excerpt that will have the maximum amount of characters up till 250, but will likely end with a full sentence.

There is still the case that no dot is present in the first 250 characters, so you will have to test the output of the preg_replace. But more often then not, the above will work.

Now let’s look at what is happening.

/(.{1,250}

Immediately from the start we open a sub-expression to match the beginning of the text. The dot character gets interpreted as “any possible character except newline”. We then use the brackets to set a quantifier from 1 to 250 characters on the dot character, which means we want to match anything as long as it’s either 1 or 250 characters long.

Since the default behaviour for quantifiers is to be greedy, it will try to match the maximum amount of characters.

\.)\s

Now that we have defined the amount of text we want to match, we are going to define the ending of this match. This, as stated before, is simply a dot. We have to escape that dot as to not match everything. Then we end the sub-expression since this is everything we want.

However it’s not everything we want to test for. So right after the sub-expression I ask to match a whitespace character (\s). This will ensure that it’s actually the ending of a sentence and not for instance the URL of a domain.

.*/ms','\1', $text );

Now that we are done with the desired selection we simply state “.*” Which will match all characters zero or more times.

Then in the replacement section of preg_replace we state that we want to back reference the result of the first sub-expression, and we are done.

As you might have noticed I added a “m” and “s” to the end of my matching expression, these are global modifiers that will change the behaviour of the expression.

The “m” stands for multiline, which will change the default behaviour of starting and stopping at new lines, to match a entire text. The “s” modifies the behaviour of the “.” character to also match newlines. You will often see these two modifiers combined because without the “s” modifier a expression like /.*/m would still only match till the first newline.

Now the above is certainly not watertight, it’s just the illustrate how versatile regular expressions can be and how you can take advantage of the more advanced uses of it.

If you are interested in learning more about regular expressions in PHP I would advise you to go read the PCRE pattern modifiers page and the regexp reference page.

admin PHP excerpt creation, PCRE, PHP, regexp, regular expressions