Hannes Van De Vreken has some advice for the PHP developers out there working on projects that make use of some form of abstraction - don't over-abstract. In his case, he's talking more about the use of abstract classes and where they fit into a good overall project structure.

Some time ago I started working on an existing project, so I read the documentation before diving in. At the top of the contributing.md file there was this sentence: “Abstract when possible”. Quickly I learned the project contained more abstract classes than a normal project. This leads to too highly coupled, and often unchangeable code.

This post is dedicated on explaining why “abstract when possible” isn’t good advice. Not only in PHP, but in all programming languages.

He starts with some of the common issues he sees with abstract classes including the over-complication of abstract methods and defining all dependencies the children need even though the abstract class doesn't. To help resolve these issues he recommends the use of traits. These traits include the dependencies needed by the child classes (for example only things needed for a CSV export, not other types). He includes all the code for this particular example. Finally he looks at situations where abstract classes are okay to use. He uses the LeagueEvent package as an example, showing how it creates a listener interface and an abstract class that contains an equality check function. He shows how to refactor this as a trait too.