The more you work with object oriented programming (OOP) in your website or programming field, the more you realize there are certain design patterns that can be used to solve similar sets of problems. These patterns are only made possible because of the flexibility and security provided in the OOP way of programming. It can be beneficial to know about these patterns since a past project you are now in charge of may have used these patterns to accomplish their tasks. In my experience, learning about the patterns can also solidify your understanding of object oriented programming. Feel free to pick up the Gang of Four Design Patterns book to really grow your knowledge. Keep in mind it is written with C++ code samples and may take longer to understand than other programming books.
Design patterns are a website architect’s dream. Solve a complicated problem one time based on language constructs and re-use that solution for different variations of a similar type of problem. It would be similar to purchasing a web template for a particular industry and re-using it for multiple clients in that industry. Let’s discuss some of the patterns most commonly seen in today’s web frameworks.
Singleton Design Pattern
This is a creation design pattern that ensures only one object of a certain type exists at any given point in time during program duration. Sometimes we just need one object. However, OOP usually involves many objects created during program execution. This can cause inconsistencies throughout your program. For example, let’s assume we have an object that represents a config file. If we have multiple objects, then one object may fetch the file, another object later changes that file and updates its local data, but the initial object does not update (because programmer did not know, lack of comments, communication etc). This is an issue that will become more evident the more you program. The Singleton design pattern solves this class of issues. We make the constructor private, therefore creating an object of a Singleton type is an error. Then we have a method such as getInstance which updates a static variable. This function may create an object (call new) or return the already created object. Now the entire codebase has access to the public interface function getInstance, and we know it will always be the same created object for all requests, which provides consistency and solves our OOP issue.
Factory Design Pattern
Another creation design pattern that mimics how things are created in an actual factory. This design pattern has factory methods in the base class and we override these methods in child classes. For example, we may have a Game class that needs a wall. So we have createWall as a function in the base class. We may now have an ActionGame that derives from Game. We’ll now override the createWall in this class to return the correct object type of wall for an ActionGame. These derived classes are in essence your factory objects that manufacture the correct type for the derived class. So rather than have a hard coded new declaration, you’ll get a function like makeObject in a base class function and the derived class will override this makeObject function to return the right object for the derived class. That way, the derived class will in essence make the correct object based on its type. This design pattern is also known as a virtual constructor. There is also a slight deviation of this pattern with abstract classes. Unsurprisingly it is called abstract factory pattern.
Adapter Design Pattern
This website design pattern helps to adapt different software to a system. For example, let’s say you have a Macbook with thunderbolt ports, but you need to plug in your new microphone which uses USB. What would you do? You wouldn’t wait forever until the mic company came out with a microphone that uses thunderbolt as its source of power. Nope, you’d straddle right over to the Apple store and purchase a thunderbolt to USB adapter. This design pattern is in essence a way to create a similar feature for programming. In web frameworks, this is especially useful for distributing software to a group of people with a wide range of uses (databases). So the adapter pattern will allow the main functionality to be written, and then we can adapt it to the different database types. Hence once you instantiate it by telling the software the type of database you have, the adapter pattern takes care of the functionality of the interface.
MVC Design Pattern
The Model View Controller design pattern is a great way to organize and separate code amongst teams. Any piece of software does 3 things. Displays data, receives and processes data, and manipulates data. Literally all website software (and software in general) does this whether you realize it or not. The Model View Controller design pattern allows you to separate these tasks in well defined areas. The view is in charge of displaying the data. The controller is in charge of directing and communicating between the view and the model. The model is where all the logic and manipulation of data takes place (and will likely have connections to the database if data is stored). These different parts are all in separate logic, so you could technically give the view code to your designers to design, while programmers mess around with the model (logic) and controller. There are many frameworks that use this design pattern such as Laravel, Magento, and Zend.
Decorator Design Pattern
This design pattern adds responsibilities to different assets in a pay as you go approach rather than trying to code for every possibility in derived classes. A Decorator class inherits from the object to be decorated and provides some default behaviors. This decorator class can then be subclassed to provide additional functionality to the decoration of the main object by overriding the relevant function (for example, adding a border with a DecoratorBorder subclass). You can then decorate the object before setting it. This pattern is prevalent in the e-commerce software X-Cart, which is a beast of website software. It will help your understanding of X-Cart tremendously if you can understand this design pattern.
Observer Design Pattern
This is a great design pattern that imitates a mail subscription. There are two major objects in this pattern, one subject object and many observer objects. The subject has a list of observers that are decoupled from itself. An observer can attach or subscribe to the subject and when an important operation is done, the subject notifies all of its observers. This pattern can be seen in action for something such as a screen update. When the screen updates, different sprites may need to react or update differently based on the update. So they may subscribe to the Screen subject and on important events, the screen notifies all of its observers so they update accordingly. In slower cpu terms, if you are subscribed to an email, every time a newsletter is sent out, the observers (subscribers) are notified and sent an email.
Prototype Design Pattern
Another creation design pattern that is known for its use in Javascript. This design pattern is based on cloning objects (which is where the objects get created). So you may have an object that has a few prototype members (containment) that get instantiated in the constructor. Once the correct prototype has been plugged into the member variables, any function that needs to get an actual object can clone it from the prototype by calling its clone function. The clone function will create the object and return the correct type, since we plugged in the correct prototype in the constructor. If we want to change how the object is composed, we can just plug in a different prototype object that that derives from the base type in the main class. Javascript uses this creation pattern to allow flexibility in the language with classes and objects.
Conclusion
These are some of the more common design patterns found in web frameworks. Other common patterns you may run across include Builder Design Pattern, Facade pattern, and visitor pattern. I highly recommend the gang of four design patterns book to to get more in-depth information about how to use OOP to solve complex problems (Design Patterns – Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides). Learning how to decouple different layers in object oriented programming is a skill that an architect must know. It is also quite interesting as you look to solve more complex relationships that can be extended without having to overhaul the system.
If you are in need of a overhaul to your website or making your website run more efficiently through a better architected solution, please get a website quote from us today.
