Alejandro Gervasio is a senior System Analyst from Argentina who has been involved in software programming since the mid-80's. He has more than 12 years of experience in PHP development, object-oriented design, and most of the client-side technologies available out there. Alejandro is a prolific technical writer, and he spends his free time with family and friends who get bored and quickly run away from him each time the word "code" unintentionally comes out of his mouth.
Inversion of Control – The Hollywood Principle
Although the “Dependency Injection = Inversion of Control” equation can generally be considered valid, the concept of IoC is actually much broader. In fact, it could be said that DI is a specific use case which exploits IoC’s benefits, but it’s far from being the only one. So what’s IoC really then? Find out in this article!
The Single Responsibility Principle
Software systems should be built from a web of interrelated objects whose responsibilities are tight, neatly cohesive, and narrowed to a well-defined task. It can be difficult though to design such systems, at least in the first take, because of the pressure to get things done. Learn how refactoring your code to adhere to the the Single Responsibility Principle can help you write more robust and less fragile software.
The Open/Closed Principle
The dictate of the Open/Closed Principle is pretty much the mantra that we’ve heard so many times before: “Don’t hack the core”. The key to achieving adherence is designing your components as polymorphic elements whose behavior is defined through abstract contracts. From that point onward, you can extend them either through Inheritance or Composition. Learn more about the Open/Closed Principle with this article and how it can help you build more robust, extensible systems.
Introduction to the Law of Demeter
The Law of Demeter is a powerful paradigm whose primary goal is to promote the implementation of highly-decoupled application components by eliminating any unnecessary mediators. Just follow its commandments explained in this article and you’ll see the quality of your code improve. Guaranteed.
The Null Object Pattern – Polymorphism in Domain Models
In a traditional approach, the consumer of a model must check for nulls and handle the condition gracefully when valid data cannot be returned, but this generates an explosion of conditionals throughout your code. Fortunately this tangled situation can be sorted out simply by creating a polymorphic implementation of the domain object using a design pattern called Null Object. Learn more about the benefits of Null Object with this article.
Constructors and Breaking the Liskov Substitution Principle
PHP allows us to specify constructors in the definition of an interface, but this could lead to big trouble since object construction is not part of the contract honored by its implementers. Learn why the implementation of different constructors down the same hierarchy isn’t a violation of the Liskov Substitution Principle.
The Template Method Pattern – Override Strategy Logic
The Strategy Pattern isn’t the panacea it promises to be, so is it possible to eliminate duplicate logic via Inheritance rather than Composition? Indeed it is. Learn how the implementation of Inheritance-based solutions, such as those that make use of the Template Method design pattern, can be effective when the steps of your algorithm should be selectively overridden by subtypes while keeping the common logic safely encapsulated in a base type.
Subtype Polymorphism – Swapping Implementation at Runtime
Any generic reference made to Polymorphism in OOP is, most of the time implicitly assumed as the ability exposed by a system for defining a set of interfaces which in turn are honored by different implementations. This kind of Polymorphism is commonly known as subtype Polymorphism. In this article you’ll see how to exploit the virtues that Polymorphism offers through the development of a pluggable cache component, the core functionality of which can be expanded later to suit your needs through the development of additional cache drivers.
Patterns for Flexible View Handling, Part 2 – Using Decorators
The Composite and Decorator patterns are among the most overlooked paradigms in PHP, but can provide for more flexible view objects. this is the second in a two-part series discussing the patterns, this time focusing on the Decorator pattern.
Patterns for Flexible View Handling, Part 1 – Working with Composites
Ever since MVC started making inroads in the PHP community, the acronym’s “V” has been unfairly reduced to the level of a plain template whose responsibility was limited to rendering a few HTML pages, but views not only can be full-fledged objects carrying state, but also observers of a model, flexible enough to accommodate and react accordingly to fluctuations whenever the model’s state changes. In this two-part tutorial you’ll see how you can implement from scratch a couple of customizable view handling modules by sinking our teeth into the goodies of the Composite and Decorator patterns. In this part we’ll focus on the Composite pattern.