Editorials

Breaking Software Principles

Today I wanted to open a conversation about one of the SOLILD principles, because I have observed that talented software developers do not often practice the Open/Closed principle.

Overview of Solid

S – Single Responsibility. A class does only one thing.

O – Open / Closed. A class is open for modification but closed for changing the interface.

L – Liskov Substitutio. Types should be able to be replaced with Sub-types without breaking a program.

I – Inteface Segregation. Better to have small interfaces rather than one large general purpose interface.

D – Dependency Inversion. Depend on abstractions rather than tightly binding separate processes.

The open/closed principle is one that I have seen ignored frequently. Part of the reason seems to be, from my observation, that we can modify software quickly, and translate it handily during conversion.

Another observation is that when using code generation tools such as Entity Framework, it does not implement open/closed principles. As a result, there are limited interfaces available to the developer when using code generated by Entity Framework. This means that when you change your data structure, you code changes and replaces the interface if an existing object is modified.

Automated code generation tools lead to a couple of different principles I’d like to call into question. The first is that your user interfaces should not define the data structure of a relational database. The second is that of the Open/Closed principle.

What do you think? The main goal of writing software is to ship working code; not to make the most elegant malleable code. So, because our goal is to ship software do we relent on our principles somewhat in order to deliver fast? If we do relent, what is the cost for maintenance?

Share your thoughts here or by email to btaylor@sswug.org.

Cheers,

Ben