Alexandre Debril

web programmer & open source contributor

In a previous post I stated that "when you want to write a singleton, drink a single malt instead". I also mentioned the "Golden Hammer" pattern which leads to poor design and low maintainability. The bottom line of it is : code design is not made of simple recipes you can use for every need. It is all about analysis and thinking. And it's something you can (well, must) apply every day.

Application development is a world of rules. Unless you lived in a cave the last twenty years, you're aware of design patterns, SOLID principles, test-driven development and some other best practices, you may even apply (please: not the singleton). The principle of least astonishment is not one of them in the first place, it was mostly established as a rule of thumb for user interfaces. But if we think about it, it's a rule we can apply on software design and architecture.

Continue reading

Thanks to Jon Lemaitre's excellent article "A Response to PHP the wrong way", I recently discovered self-exposed as the counterbalance of Then came the need to write an answer on the subject, my views on framework, OOP, standards and the rest but I realized I would end up with a very long article full of obvious arguments or at least statements many people already know. Boring. Seriously who wants to read another pros and cons on frameworks and OOP ? Is it really worth discussing it nowadays, knowing how many classes are offered by PHP itself and how its own syntax is object oriented ? I just think that if you don't want to write OOP code with PHP, you're free to use another language or to fork PHP 3.

The only subject I will cover in this post is the usage of design patterns. It could have been the wisest part of "PHP the wrong way" but the author failed to provide relevant arguments by focusing on a philosophical point of view. My goal here is to bring a more objective point of view with technical facts.

The wrong way: Looking for a pattern to solve a problem

True, this is a dogmatic approach we must stay away from. Patterns were designed to implement common needs like separation of responsibilities, open/close principle and to save some precious time finding design solutions. However, it has some drawbacks and the use of design patterns requires skills and common sense.

Continue reading