One of the issues one comes across in building performant applications in Flash is object creation and garbage collection. Object pooling helps overcome this. Object pooling is keeping old objects around and reusing them instead of throwing them away and always creating new fresh objects.

Creating objects in Flash isn't bad. It's when you create hundreds or thousands of throw-away objects very quickly that this becomes a problem.

Used Pooling in Observe

For my final implementation of the Observe class I use objects to temporarily store information about hooks and observers that allows me to sort them based on order they were added. At first I thought how unfortunate that I have to create objects to do this when one of the major reasons for creating Observe is to eliminate the creation of Event objects every time a property change happens.

Fortunately I have complete control over Observe and its implementation (unlike Flash's Event model) and I can pool these temporary objects. Setting up pooling is very simple and I'd like to demonstrate how it can be done by pretending we're building a super-fast memory efficient best-performance tween engine. We'll go with this use case, build pooling, and let the remainder of the tween engine be left to the imagination or as an exercise of the reader to finish.

Tweening Ultra-Speed

Our pretend tween engine is called Tweening Ultra-Speed, because that sounds super cool. Super duper cool (k, so it's late). The biggest problem with high-peformance tween engines like GreenSock's preventing them from pushing beyond their top speeds even further is object creation and garbage-collection. In order to create a new tween the API might look like this:

No big deal, right? Unless you're pushing the limits and creating thousands of these every second. The object being created between those parentheses is being allocated some memory and then garbage collected later. Memory builds up as thousands of these are called, then drops back down (with a noticeable pause in the animation) because the garbage collection cleans up the old objects.

How else could we do this?

We need to have objects that we can reuse. We might go specific and have a MovementTween that holds the x/y properties. We might do a size tween that holds the width/height properties. I'm going to go with generic and do a property tween for each type of property. For now, we will cover 90% + of tween use-cases with a NumberTween object.

I'm keeping it simple and not including other stuff we might need such as current value and delta value, easing, and stuff like that. Now we have a concrete object that would be used like so:

Of course, this doesn't solve the problem yet, but now that we have a concrete class, we can make a pool for NumberTweens. My favorite way is to add a static method on the class and using a link-list. It is very fast and light, and I think very elegant.

The important things to note here are the static get and put methods. You now use get to retrieve a new NumberTween instance and put to "release" it back to the pool once you're done with it. If your pooled object points to any objects or non-mutable types (non-string/number/boolean) this could be where it gets cleaned up too (don't keep mySprite tied in memory to a pooled Tween object). I've also made a method called destroy that does the same thing, puts it back into the pool. Let's say we do something similar for our Tween class as well.

Once the tween has finished running it can call a Tween.put() on itself which might call property.constructor.put() on all of its properties. The great part for this particular scenario is that you can have NumberTween, ColorTween, BlurFilterTween, etc. for each type you want to support! Now we may be creating thousands of tweens every second but we're recycling object instances so that object creation is limited and garbage collection isn't slowing things down. What is it they say? "Reduce, reuse, recycle."

This is my take on object pooling. You could create a pooling framework, but it is so simple to add pooling to a class, it doesn't seem necessary for quick things. And this pooling would speed up tween engines that much more (at the expense of more lines of code to create a tween. There are trade-offs).

So who's going to finish my tween engine for me?

We (actually just myself right now) hope for this to be a good learning experience for others and are blogging about our design decisions how we are putting it together along the way. This way it can be more of a case study in progress for others to learn in a more of hands-on way about object oriented programming.

Anyone is invited to help out, whether they know object oriented programming or not. If OOP isn't a strong point, then you can just help coding (with guidance if desired). If it is a strong point, then you can help in the design process as well and post some blog posts too. I can do the design, database, classes, and all, but it would be a better project with more minds at work on it. It will also be finished sometime this century. Thank you for your help.

What's in our Model

Well, first off, we know we need a database to store all of our store's data. We'll put off the database schema for now. But what we do need to decide is what database to use. And if we want to support several databases (which we do), what should we do to abstract the databases so that we use the same API no matter which database we use.

There are a few object-oriented options out there. My favorite is Creole, a PHP 5 database abstraction layer which has a nice interface. There is also PEAR's DB which I've actually never used and have heard good things about. The good things about these are that they're already built and they are actively developed which means others are fixing the bugs and adding features so we don't have to. However, they are large, and the API of Creole is more of what Java programmers are use to and not what PHP developers are use to. We could also create our own object oriented abstraction layer. It would be smaller and use the API we want. Much more simple code. What do you think we should do?

The rest of the model would include the following list of objects, plus maybe a few we havn't thought of yet:

• Customer
• Address Book
• Address
• Payment (stored)
• CustomerGroup
• Order
• OrderItem
• PaymentMethod
• DeliveryMethod
• Product

• ProductReview
• ProductSpecial
• Catalog
• Category
• ShoppingCart
• Translator
• Pages
• Content
• Administrator
• Report

There of course will need to be an object type for each method of payment and other additions like that. But I think we've got a pretty good layout here. We may think of other things later, especially when we want to add features.

How Will We Control Our Model

The controller part of our system could be pretty simple, or pretty elaborate. It all depends on what we value the most. If we like simple the best, we can just have a bunch of PHP pages that our use will go to, they will run the code they need to run, using the model objects, and then they will pull in a template and output the results. The URLs for these will be the name of the files, plus any parameters passed in the URL. These will be pretty procedural, although we could make them into classes to keep it object oriented. Another option is to push for search engine optimization by building our system with URLs that represent the page being displayed. If we go simple, we will have a "product.php?id=10" or "product.php?name=james_bond_movie" displaying our products. If we choose the more complex controller we would have "products/james_bond_movie" be our URL, which ranks it higher on the search engines. To do this we would need to use mod_rewrite with Apache and set up our scripts to handle these URLs. But it is very do-able. Do we want full-featured, or do we want simplicity? The value of ooCommerce will be higher with better features to it's users.

Gotta See The View

There are a million and one template systems out there (I wrote the 1,000,001 template system) and most very similar. Smarty is the most popular it seems. And most are similar to Smarty except less features or slower. I happen to be partial to my templating system, Arras, which is different from most. It is also fast, and small, and fun to use, and easy for designers to do design on. So, I would like to use Arras.

So, what are your thoughts? Please give feedback on the following design decisions. We would love to get input.

• What database abstraction layer should we use?
• Any additional classes I forgot in the model?
• Go for a simpler controller, or nicer URLs?
• Use Arras for the template system or something else?

Every ecommerce system has a few major parts in common. One is the catalog. This is where we can browse and search for the products. Then, we have the shopping cart. This is where we put the products when we want to buy them. We have our checkout, which is the process where we can purchase what is in our shopping cart. And lastly, many systems including ours will have a customer account section, where we can view our past orders and get support. Actually, we are fogetting a major part of the system. The administrative section. This can sometimes be the largest section and will help us organize the catalog, oversee orders, configure the system, and all the other administrative tasks associated with running an ecommerce store. Here are the "main sections."

We will be storing many of the store's information in a database. So we will need a database package (when I say package, it might be one class or a group of classes, we can figure out which later). We also want to keep the HTML and style of the site seperate from the code as much as possible so that it can change. This is a very important piece that osCommerce has not done well in. It can be very difficult to reskin osCommerce. So we will have a template package. We want to model an actual store in our code for a simpler and easier to code/understand system. This part will be the model and will be the one to interact with the database. Finally, we need something that takes the pages or actions of our store user, puts together the model information and the templates, and gives it back to our user. This will be our controller. So, we have a model, view, controller system we will be making. It will give us greater flexability. Here are the "MVC sections."

The MVC (model, view, controller) sections aren't different from the main sections described above. Rather, they are another way of looking at our system. We will have a customer class (from the model) used in the admin section, the shopping cart section, the order section, and the customer account section. The main sections above indicate the sections of the website, and the MVC sections indicate the different layers of code we will use in the website.

Right now we haven't gotten to our classes yet. We've just been breaking the system up into smaller pieces. These may be organized into folders of classes or they may just be for our own reference.

We have successfully broken down the system one level. We will look at breaking down the system into small parts next time. We are on our way to a successful ecommerce solution.

The Project

Going back to my roots, I learned to program by hacking on osCommerce code. I wanted to make my own ecommerce site and run my own buisness. It was then that I discovered how enjoyable programming was and stuck with that instead. The problem with osCommerce is, however, that it is very procedural. It has SQL queries inline with the HTML on it's pages. It uses functions to output pixel images. It requires a lot of hacking to modify. It is an adequate example of what you might call "spaghetti code."

ooCommerce

We will be starting a new open source project that will implement all the features of osCommerce, but in a better way. And hopefully, since this will be more extensable, we can add many new features. We can call this project ooCommerce for object oriented ecommerce. I have already purchased the domains oocomerce.com, .net, and .org so that we may, eventually, have our own site for it. And I have submitted it to Sourceforge for pending approval. The benchmark of features we will be aiming for is listed on osCommerce's site. And, because we are going full out object oriented, we will be using PHP 5. I am sorry if you were hoping for PHP 4, but in order to teach better OOP principles, and because PHP 4 is such a hack in terms of OOP, that's what we need to use.

I hope ooCommerce will be, if nothing else, a great learning experience. Instead of a little pointless tutorial on saying "hello world" in an object oriented manner, we will actually create a full-featured system as our tutorial, implementing all that we've learned previously. We will look at planning this project out next week, so stay tuned.

Single Directory of Classes

This is the simplest solution, and the best if you have a small project. You may have situations where you would like to load the class without creating a new instance of it, so I will be creating a loadClass function in each example which __autoload will call. That way you may load a class manually. Here is what you might do if all of your classes are in one directory:

Pretty Simple.

Packages of Classes

Now how about package management, with many directories of classes? A few developers have named their classes with the package names in the class name. For example, util_Parser would be the Parser class in the util directory (in your base classes directory), and util_html_HTMLParser would be the HTML parser class in the util.html package. Here is an example of how that would work:

Simple like the first method, but we get packages now. However, we have to actually name our classes with the package names in front of it. We start to get very long names for some of our classes. If we extended the Parser class we might have util_html_HTMLParser and util_xml_XMLParser or perhaps even deeper packages. We also find refactoring difficult because if a class must move to another package, we must go through all our code and rename the class everywhere we use it.

Package Management Using import

There is another way, although not as simple, which allows packages as deep as you would like, and requires minimal work when refactoring. This is the import way of doing things. import is a function which keeps track of what classes you might use in a certain script/class and then uses __autoload to look up the location of the class. Here's how it works.

• You import the class or package using the import function like this, import('util.html.HTMLParser');, at the top of your script
• import stores the name of the class, 'HTMLParser', and the path to the class, 'util/html/HTMLParser.php', in a global associative array called imports
• When the class is utilized, __autoload will do a lookup in the imports array for the class and load it in.

Here is how the code looks. It is a bit more complicated, but very nice to use for a larger system:

There you have it. A powerful way to manage your packages and load only classes which are needed for use. Also, a feature of this method of autoloading classes is that you can use an asterisk, *, to import all the classes in a package. And it only loads the classes needed because of __autoload.

Finally, this is how you would use the import method in your scripts:

First, here is the problem being solved. Do you ever find yourself setting and object (or array, or variables) from a HTTP post in the following manner?

Don't you think it would be easier to do this?

This can be done by having the User class extend the Object class. The Object class has a method called setProperties($params = $_REQUEST, $properties = '*', $prefix = '', $force = false) which by default sets all the properties that an extending object has from the $_REQUEST.

There are many other ways you can use this method. You can set another source to populate your object from, including $_GET, $_POST, another array or even another object. You may also limit which properties are set by passing them into the $properties parameter in a comma delimited list. To set all properties you pass '*'. To set only some you would pass 'prop1, prop2, prop3.' If you want _all_ the properties set except one or two you may add a negative sign in front of the property like '*, -prop1, -prop2', '*' says use all, then the '-prop1,-prop2' would exclude those properties. In addition you may add a $prefix to the properties. This is useful if you have two objects and want to set both properties this way (ie. firstName, shipFirstName, billLastName). It takes care of the camel-case for you. And finally, there is the $force parameter. The default is false which means that only properties currently in the object will be set from items in the $params array/obj. By setting $force to true you may force all items to be set on the object. This is useful when you have an empty object, or one that has no class definition.

Now, here is what you've been waiting for. The setProperties method to add to any class (or even better, any parent class).

I threw in the bonus getProperties() function :)

I hope this can save at least one developer some repetative coding in their application.

No more of this element wrapper stuff. I don't want to code my classes to act upon a DOM element. I want to write them as if they actually arethe DOM element, just a specialized one. This makes much more sense to me as I am working with the objects of the DOM.

Here is the code:

You can just add this to your Prototype library or something. Then start making your components.

The way to use this is pretty straightforward. First, you create a new "class" like so:

Let's walk through this step by step. First, I create a new class called MySentence. It will be a paragraph element and it will have some text inside of it (the contents are not required). Simple enough. I can then declare my prototype for the class which will contain all the methods of my new class, including an initialize method which will be called if it exists. In the initialize method I find the STRONG tag and assign it to the property "word" for use in my other method, rewrite. That method just changes the word inside the STRONG tag. I now have a class that when created, will be a paragraph with some great text inside of it and a method to rewrite the word "great." You may even try it out and see it working in action. Here is a fun test:

Putting all of the above code in a HTML page will give you some text that when clicked on, will change the wording. Pretty useful huh! Ok, so maybe this particular example isn't uber useful, but coding new objects, widgets, and components might be easier. At least a little bit. You may see the above example in action.

I'll see what I can add onto this to make it better. Perhaps something where you can access the tags inside by saying this.word = this.strong[0]; instead of having to loop through all the children.

This class works for both IE 6 and Firefox. I would be very interested to know how many other browsers it worked on.

I have another javascript goody that my friend Derek and I worked on together which is pretty cool. I'll share that soon too.

• An Introduction to Object-Oriented Programming
• Thinking Object-Oriented
• Planning an Application
• Creating Objects
• Making Objects Reusable

In the previous three object oriented programming articles written for jacwright.com, we introduced object oriented programming, spoke of thinking about a system object oriented, and discussed the importance of planning, even if only in one's head. The next two articles, Creating Objects and Reusing Objects, delve into the meatier subject of writing objects. We will be discussing how to implement the plans we've made and the systems we've conceptualized. Without these principles, object oriented programming can become a mess instead of a blessing.

Encapsulate, Encapsulate, Dance to the Music (lyrics)

Encapsulation means keeping your business to yourself. Objects can't be bothering others with their issues. Other objects have their own stuff to worry about. When we create an object it needs to have methods for other objects to speak with it, but it should rely on others as little as possible. There are two terms we use to describe how encapsulated an object is: "black box" and "white box".

Black box describes an object that is completely encapsulated, closed up, secretive. We don't know anything that's going on inside of this type of object. We also can't see anything inside it. We must ask it for anything and everything we want to know about it. For example, a black box object has "getters" and "setters" to access it's properties. A getter or setter is simply a method that returns the object's properties. So instead of looking at the object's properties directly, we must request the properties through these methods.

White box describes an object that is not quite so into security. It doesn't care if other's know what it likes for breakfast or it's favorite color. Often we access it's properties direc

tly. It may also require us to know more about it in order to use, making it not as easy to use. It may be more needy than a black box object, wanting us to find out about it. We may need to pass it's properties around to it's methods and/or call several of its methods to accomplish one task.

It's Not Just Black and White

Although these terms, black box and white box, help give us a way to describe objects, it's not so black and white. There are varying shades of gray in between. But black box is best, right? Well, again, things aren't so simple. Writing a black box objects means that we need to take more time to write it's getters and setters and make sure only necessary methods are publicly accessible. White box objects can be quicker to build and give us more control over the object. They also don't have to be written to be needy. Black is generally more user friendly (because we don't need to know more than we have to) and white is generally more flexible (because we have more control outside the object).

When is a good time to use black box, and when should we use white box then? Good question, glad I asked. If we are creating an object that we will be releasing to the world, or an object that is going to be reused over and over, or an object that we want to be used in just the right way and not any other, we would probably go with a darker shade of box. If the object in question is only going to be used once, if it will only be used by us, or if we want the object to be as flexible as possible.

Extend

Extending an object is having sub-objects based off of the parent. It helps us reuse code, but at the expense of greater portability. We may have a person class with child classes extending it of customer and employee. We may put the similar code in person that customer and employee both share, such as name, address, and a method to store the object. We can then put the unique code in the child classes. Employee will have payroll information and maybe a method to give a bonus. Customer will have a shopping cart and maybe an account.

Extending is a great way to reuse code, and it makes good sense. We are able to reuse code effectivly between related objects, and if there needs to be a change (for example, we now want to keep track of first name and last name seperatly for all people in our database) then we only need to change it in one place. We also can make the child objects fully black box so that nothing need be known about it. However, if we ever wanted to use our Employee class in another system, we would need to make sure we brought it as well as it's parent class, Person, over to the new system.

Beware Family Trees

There is a caution to be added here. It may sometimes become tempting to create whole family trees, reusing code from the whole system. This is generally a bad idea. Inheritance may work best when it is only a few generations. The reason for this is simple. As stated above, if we wanted to reuse an object in another system, we would have to bring the whole tree over with the object. It also can start to become confusing with so many classes dependant on others. The only time I would suggest extending more than a few generations is when creating a system such as a framework, a component set, a module or something else that would always be packaged together. Even in these situations, there may be a better way to use functionality if it makes sense, and that is object composition.

Compose

Object composition is another way to reuse code. Unlike extending where we inherit methods and properties from parent classes, with composition we make an object with other objects. This could be likened to the human body, one complete object made up of many other objects. The body ties everything together, helping the heart, the braing, the lungs to all work together. The customer's shopping cart in the previous example could become a seperate object that belongs to the customer. This may make more sense, to keep objects more simple. It increases organization. Of course, like anything else, to much of a good thing can be bad. We wouldn't want the customer to have a name object which contains his first name and last name. We would start to have more objects than we knew what to do with if we were breaking them down so small.

Composition is used very often, most any object oriented programs. Larger objects are made up of smaller pieces. It also can be more reusable. The employee object could be used without needing his payroll object and other (non-essential) objects that make him up.

Object Creation

Creating objects is a balancing act. Many decisions are made (often subconsiously) about how encapsulated to make an object, how to extend it, and how to compose it. The road to becoming proficient at object oriented programming may often start out with too few of these principles implemented. Then, once they are learned, it may become overused, making systems too complex. Finally, a middle ground will be found when it is remembered that the underlying purpose of object oriented programming is not to reuse but to simplify and organize.

Why Object-Oriented Programming?

The discussion began with a question, “why [do] folks like OOP so much in PHP?” Few of responses attempted to answer the question but most seemed to agree that perhaps OOP is over-rated and used in too many circumstances. I would like to answer that question for anyone interested and to explain why people like object-oriented programming.

In My Beginning

I began programming two years ago. It started with my brilliant idea to start my own ecommerce company selling computers and stuff related to that. I downloaded the latest version of osCommerce and got my store all set up. Of course, the default installation of osCommerce is never enough (especially if you want to brand your store nicely) and so I started hacking away at the code not knowing much HTML let alone any PHP. Soon I taught myself PHP. In fact, I loved making MY code work in the browser so much that I changed my career path and decided to be a programmer (it was a hard decision; I didn’t want to become a geek). I got my first job doing PHP and became an excellent procedural programmer (I learned PHP from osCommerce after all, not saying that it is excellent though, just procedural).

My father, a traditional C++ programmer (another reason the decision to become a programmer was hard; didn’t want to be as geeky as him; sorry Dad) who has worked for companies such as Eyering, WordPerfect, and Novell told me about object-oriented programming and how it was just better. I assumed he knew best since he’d been around longer than I (much longer). So I learned as much as I could about OOP and started programming that way.

It was difficult at first. It was very hard for me to conceptualize how things were supposed to work as objects. But I felt it was exciting too. I was learning more about programming and how to be a better programmer. It is because it was difficult for me to start thinking in terms of objects that I am writing articles about such. The writing of classes and methods was easy. It was doing the whole system correctly that I struggled with. I guess what you would call OOP theory and design.

At Present

Since that weak start two years ago I’ve become proficient with OOP. I’ve learned Java (not by choice, but still, not bad huh?) and done a couple of large projects with that. Of course, PHP is still so nice to program in and I was very grateful when I was able to come back to it. I’ve done many projects that were OOP. I’ve gone back and worked on projects that were procedural. I know all sides of the fence intimately.

Why?

Object-oriented programming is easier. Once you know it, it becomes such a pain to work on a project that is procedural. It is just so very much easier. Everyone I know who knows how to program object-oriented, uses it in everything except for the smallest of applications or scripts. If it’s a simple script, procedural all the way. But if it’s an application of even small size, OOP just makes it easier.

Some say it seems there needs to be a LOT of structure for an OOP program. Actually, it provides a lot of structure, and MAKES IT EASIER. There are concerns that the program runs slower. Are we seriously concerned about this? Class definitions are not heavy. This is not Java we’re talking about, like a whale sitting in your memory. We probably have to measure the difference in clock cycles as opposed to milliseconds. Besides, web applications are a little slower anyway, that’s why we use PHP, an interpreted language, in the first place. It speeds up development and the applications are never so robust that doing it in C would be desired (except for search engines and such, but they probably don’t use C for generating the HTML pages).

Object-oriented programming is just procedural code organized to another level. It makes things so much easier (yes, I keep saying that, but I think that’s why people are scared of it, because the feel it makes things MORE complicated). The only time you wouldn’t use it if you knew it would be when writing small scripts. I recently wrote a database transition script to move all the data from one database schema to another. It’s like a baby who won’t walk because they can crawl just fine. Sure, there are times when you need to get down and crawl, but you aren’t going to make that your default mode of transportation.

Object-oriented programming is an “oft overused methodology.” Said by one who I’m sure has probably seen some really bad OOP code used as a hack. There is plenty of bad OOP code out there as there is bad procedural. Looking back for example, I would say osCommerce is bad procedural code. The database queries are scattered throughout the pages. Good procedural would centralize things and use functions to access them, so when there are changes you don’t have to hit every single file. OOP is the same way. You can make it really, really bad. But OOP itself is still better.

PHP is not true OOP at heart. Yes, true, but that does not mean that programming object-oriented in PHP will make things more difficult. It still makes things easier. Even in PHP 4. PHP 5 does make things a whole lot nicer, but PHP 4 applications are still easier to make when we use objects. I’m not saying every ounce of code should be an object or a class. But the general application will be easier to program (for those who know both procedural and OOP) if it is done object-oriented.

Conclusion

There can be great procedural programs. You don’t need OOP. But it is the next step to becoming a greater developer and being able to write easier and more maintainable code. It is not a marketing scheme (like Java is) with someone trying to make a profit off of it. It is a way that helps us develop programs easier.

I know this article may upset many people. I apologize if you are offended. There is a reason why so many folks like OOP. And it is that it makes programming easier, debugging easier, refactoring easier, upgrading easer, and expanding easier. There are no major drawbacks to programming web-apps OOP, just benefits. Only low-level drivers, operating systems, or search engines and like systems. But no one in PHP will be writing anything like that. I hope.

I may not have been a developer for 20 years, but I do know that just because you have, you are not necessarily a great programmer. And I know that there are great programmers who have only been developers for a few years (I hope I can be one of them). But I have never met anyone or talked with anyone who has programmed object-oriented for years and felt it was over-used or that procedural was generally better. I was very supprised that people felt OOP was not a step up.