Stupid or Solid?

What is S.O.L.I.D.?

• S: Singleton
• T: Tight Coupling
• U: Untestable
• P: Premature Optimization
• I: Indescriptive Naming
• D: Duplication

Use Cases of S.T.U.P.I.D.

Singleton

When the singleton trait is present, that means that there is one class of code for the entire project. This trait can be useful when the following conditions are present:

• Making sure there is one instance of a class
• Ensuring accessability of a class
• Controlling instantiation
• Instance restriction
• Global variable accessibility

The main drawbacks of this desing pattern is that this does not allow for test driven development, no inheritance, creation control is restricted, and requires all dependencies to be changed for each instance

Tight Coupling

Tight coupling is not much better than singleton development, due to the over reliance of code throughout a project. By implementing this strategy of development, there could be a trickle down effect on the project if one dependency breaks any file that uses it. Thus, multiple files need to be changed. Additional drawbacks include difficult code reuse in the future and inhibits the ability to test the project.

Untestability

Testability in a code base should be easily implemented and should be an integral part of the development cycle. Most times, if a project is too tightly coupled, then the ability to test your code base is inhibited. Thus, testing should be implemented along the way, rather than at the end of development when time and capitol for the project could be running low.

Premature Optimization

In this pattern, the cost of the project outweighs the ability for benefits. In this day and age, is detrimental to product development and especially to product security. If cost is an issue, then features, testing, and security will be cut rather than implemented. As such, with cost becoming a factor the code will take a step back in both performance and readability for future improvements or reuse.

Indescriptive Naming

This is pretty self explanitory, using descriptive names for variables reduces the need for comments and is appreciated further down the road for maitenance, feature implementation, and code reuse.

Duplication

This is on the same wavelength as indescriptive naming, if there are duplicated functions then time is wasted and coupling is affected by the multiple ways of doing the same task.

S.O.L.I.D.

S.O.L.I.D. is the complete opposite of S.T.U.P.I.D. and covers the following design priniciples:

• S: Single responisibility
• O: Open/Closed Principle
• L: Liskov Substitution Principle
• I: Interface Segregation
• D: Dependency Inversion Principle

Use Cases for S.O.L.I.D.

Single Responsibility Principle

This design pattern involves only having one purpose per class. This allows for both low coupling and high cohesion in a project or code base. The rule of thumb to check for this principle is the following: Is there more than one reason to change this class? If there is more than one reason, then the single class can be split into multiple classes.

Open/Closed Principle

• Open: open for extension, this applies to adding data structures and fields to the functions contained within the class.

• Closed: closed for modification, this applies to internal variables which should be private and accessed by getter and setter methods for the class.

Liskov Substitution Principle

The Liskov Substitution Principle (LSP) applies to classes where a class can be replaced with an instance of their subtype without losing functionality or correctness of the class.

Interface Segregation Principle

This design principle refers to not having a generic interface for multiple use cases. This principle specifically outlines low coupling and high cohesion among classes within a project and minimizes the dependencies among the classes

Dependency Inversion Principle

The Dependency Inversion Principle has two main attributes:

• Abstractions should not depend upon details
• Details should depend upon abstractions

By applying this design principle, a code base or project will have reduced dependencies within the project and allows for future code reuse.

My Thoughts

After looking through the following design principles, S.O.L.I.D. is more modern and I have attempted to add these principles to my code projects and they are a a night and day improvement over S.T.U.P.I.D. Hopefully going forward, I can use these principles throughout my projects and applications that I develop.