Category Archives: Programming

“The Clean Code Talks” are fighting if statements

Just found this 4-year-old video which can be very instructive :  Misko Hevery fights against if/switch statements using object oriented techniques to remove them.

“The Clean Code Talks — Inheritance, Polymorphism, & Testing” – YouTube.
Continue reading “The Clean Code Talks” are fighting if statements

if-else trees vs SOLID principles

Introduction

If you have read my previous articles, or know me personally, you must know that the one kind of bad code I hate the most is if-else trees. In the first article of this weblog, I talked about if-else trees in general, exposing some general ideas about how to avoid them, remove them from the code or why they are bad, describing them as a code smell.

Today, as I have just finished writing a series of articles in French about the SOLID principles, I am going to focus on the maintainability aspect of if-else trees, and make them fight against two of the SOLID principles: the Single Responsibility Principle and the Open/Closed Principle. This will allow me to introduce some important rules to know about if-else trees. Continue reading if-else trees vs SOLID principles

SOLID Partie V : Dependency Inversion Principle

Introduction

Le Dependency Inversion Principle (DIP) réside en deux règles:

  1. High level modules should not depend upon low level modules. Both should depend upon abstractions. ( Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d’abstractions.)
  2. Abstractions should not depend upon details. Details should depend upon abstractions ( Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.)

SOLID Partie IV : Interface Segregation Principle

Introduction

Comme toujours avec les principes SOLID, l’enjeu est la maintenabilité du code. On s’intéresse en particulier au couplage. Si ce n’est pas déjà fait, je vous invite à lire SOLID Partie I : Single Responsibility Principle car les idées défendues dans l’Interface Segregation Principle (ISP) sont proches de celles du SRP. En effet, alors que le SRP défendait l’idée qu’une classe ne devrait avoir qu’une seule responsabilité (“il ne devrait y avoir qu’une seule raison de changer une classe”), l’ISP va plus loin en appliquant ce principe aux interfaces. Continue reading SOLID Partie IV : Interface Segregation Principle