An Interest In:
Web News this Week
- March 27, 2024
- March 26, 2024
- March 25, 2024
- March 24, 2024
- March 23, 2024
- March 22, 2024
- March 21, 2024
The Whens and Whys for PHP Design Patterns
There are plenty of articles that explain what design patterns are, and how to implement them; the web doesn’t need yet another one of those articles! Instead, in this article, we will more discuss the when and why, rather than the which and how.
I’ll present different situations and use-cases for patterns, and will also provide short definitions to help those of you who are not so familiar with these specific patterns. Let’s get started.
This article covers some of the various Agile Design Patterns, documented in Robert C. Martin’s books. These patterns are modern adaptations of the original design patterns defined and documented by The Gang of Four in 1994. Martin’s patterns present a much more recent take on the GoF’s patterns, and they work better with modern programming techniques and problems. In fact, about 15% of the original patterns were replaced with newer patterns, and the remaining patterns were slightly modernized.
Let’s Start by Creating Some Objects
Use a Factory Pattern
The factory pattern was invented to help programmers organize the information related to object creation. Objects sometimes have lot of constructor parameters; other times, they must be populated with default information immediately after their creation. These objects should be created in factories, keeping all the information regarding their creation and initialization contained within a single place.
When Use a Factory Pattern when you find yourself writing code to gather information necessary to create objects.
Why: Factories help to contain the logic of object creation in a single place. They can also break dependencies to facilitate loose coupling and dependency injection to allow for better testing.
Finding the Data We Need
There are two frequently used patterns to retrieve information from a persistence layer or external data source.
The Gateway Pattern
This pattern defines a communication channel between a persistence solution and the business logic. For simpler applications, it can retrieve or recreate whole objects by itself, but object creation is the responsibility of factories in most complex applications. Gateways simply retrieve and persist raw data.
When: When you need to retrieve or persist information.
Why: It offers a simple public interface for complicated persistence operations. It also encapsulates persistence knowledge and decouples business logic from persistence logic.
In fact, the gateway pattern is just a particular implementation of another design pattern that we’ll discuss shortly: the adapter pattern.
Go with the Proxy
There are times when you can not (or do not want to) expose the knowledge of the persistence layer to your business classes. The proxy pattern is a good way to fool your business classes into thinking they are using already existing objects.
When: You have to retrieve information from a persistence layer or external source, but don’t want your business logic to know this.
Why: To offer a non-intrusive approach to creating objects behind the scenes. It also opens the possibility to retrieve these object on the fly, lazily, and from different sources.