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.

Alejandro's articles

  1. 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!

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. Patterns for Flexible View Handling, Part 1 – Working with Composites

    This entry is part 1 of 2 in the series Flexible View Manipulation

    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.

  10. An Introduction to the Front Controller Pattern, Part 1

    This entry is part 1 of 2 in the series An Introduction to the Front Controller Pattern

    The primary role of a front controller in web-based applications is to encapsulate the typical request/route/dispatch/response cycles inside the boundaries of an easily-consumable API. Tunneling all requests through a single entry point is an efficient way to implement a command-based mechanism, which not only allows you to route commands to appropriate handlers, but also exposes a flexible structure that can be scaled without much burden. This is the first in a two-part series exploring some straightforward approaches to implementing an expandable front controller from scratch.

  11. The Layer Supertype Pattern: Encapsulating Common Implementation in Multi-Tiered Systems

    Despite the pitfalls and oddities rooted to Inheritance, most of which can be mitigated through rational and moderate use, its charming influence is hard to resist. Code reuse is, after all, the reason why Inheritance lives and breaths in the first place. Learn more about Inheritance and the Layer Supertype Pattern in this article which shows you how you can encapsulating common implementations in a multi-tiered system.

  12. Managing Class Dependencies: An Introduction to Dependency Injection, Service Locators, and Factories, Part 1

    This entry is part 1 of 2 in the series Managing Class Dependencies: An Introduction to Dependency Injection, Service Locators, and Factories

    This two-part series is a quick roundup of some of the most common methodologies that can be employed for managing class dependencies in modern application development, ranging from using service locators and injectable factories, to sinking your teeth into plain vanilla Dependency Injection, and even implementing a naive Dependency Injection Container.

  13. Decoupling Interfaces from Implementation – Using Separated Interfaces

    Separated interfaces allow you to set up loosely-coupled client modules in a straightforward fashion which define the contracts that should be used by other packages. They’re not just another twisted, hard-to-understand pattern with little or no real application in the real world. The logic behind separated interfaces is a lot easier to digest than you might think, and they bring a plethora of benefits to the development table. Learn more about them in this article.

  14. Implementing a Unit of Work – Handling Domain Objects through a Transactional Model

    CRUD applications that don’t encapsulate extensive chunks of business logic can quickly become bloated and generate a lot of overhead when it comes to performing multiple database writes. What if they reach a point where it’s necessary to handle a huge number of domain objects, which must be persisted and removed in sync, without compromising what us programming plebs loosely call data integrity? The Unit of Work (UOW) pattern to the rescue!

  15. Handling Collections of Aggregate Roots – the Repository Pattern

    Dealing with the oddities of a layer of Data Mappers is quite a burden, often dropped into a “code once/use forever” strategy. The situation can become more awkward when the model starts to bloat and increase in complexity, since additional mappers will be added over time. See how to build a repository from scratch so that you can see its inner workings and how it can tame such problems.

  16. The Dependency Inversion Principle

    The Dependency Inversion Principle talks about making both high and low-level modules dependent on abstractions, but at the same time the high-level modules must have ownership of those abstractions – a subtle yet often overlooked detail. This article shows you how you can fully adhere to the DIP in a pragmatic way in PHP, something that will surely make your applications a lot less vulnerable to future fragility and rigidity issues.

  17. An Intro to Virtual Proxies, Part 2

    This entry is part 1 of 2 in the series An Intro to Virtual Proxies

    Standing behind a rather fancy and flowery name, Virtual Proxies are quite possibly one of the most visible examples of why the “Programming to Interfaces” mantra is a lot more than just a dull dogmatic principle. See how to hook up a proxy to a specific collection of domain objects in this installment of the two-part series.