STUPID vs SOLID

 SOLID Principles were first collected by Robert C. Martin (also known as "uncle Bob"). It is the acronym for:

  • Single Responsibility
  • Open/Close
  • Liskov Substitution
  • Interface Segregation
  • Dependency Inversion

    • I will be talking about each of them in a series of Posts in this blog. But, let's talk first about the STUPID principles (believe it or not, this is also an acronym), opposite to this set of good practices, that we should avoid:

  • Singleton
    • A Singleton is a software design pattern  that restricts the instantiation of a class to one single object. This is useful when exactly one object is necessary to coordinate actions across the system. That is what theory says, but it's difficult to think of many situations which would require you to model an object with a singleton. It is, in fact, referred to as an anti-pattern. The main reason for this to be avoided is that it involves a high level of coupling, when we are in fact looking for the oppositte: low coupling and high cohesion.
  • Tight Coupling
    • As it's been explained, a tight coupling is a poor strategy as it will make it difficult for you to extend the features in your app. 
  • Untestability
    • Most of the times due to a tight coupling or to poor strategies such as calling static methods instead of using constructors.
  • Premature Optimization
    • The tittle speaks for itself, right? I know thinking big is a huge temptation when you first start developing your own app, but adding innecessary complexity won't benefit you. Small steps and clean properly written code is better than getting entangled in complex relationships between entities that you might or might not need in the future. Scalable code is the key to success!
  • Indescriptive Naming
    • I cannot insist enough in how important it is to use semantic names. You think you are good at choosing them? It doesn't matter. Before writing even the first line of code, sit down with a paper and pen and write down a brief glossary to name your entities and variables or you might find yourself refactoring a whole feature because the names you chose are duplicated, you don't even rememember what they mean or the don't represent the reality you are trying to model.
  • Duplication
    • It's such a great pleasure when you are able to reduce your 300 lines code to a readable "story" that perfectly fits in your screen and that you (as well as your granny) and other developers will be able to understand in 10 years time without comments. First learn how to make your code work, then, make it look beautiful!

    I hope this helps anyone following the hard but satisfactory path of self-learning!
    Happy coding and happy weekend 

    Comments

    Post a Comment

    Popular posts from this blog

    SOLID: The Single-Responsibility Principle (SRP)

     This Object Oriented Programming principle states that each module or class should be responsible for only one part of the functionality.  By saying this, we are stating that each subsystem, module, class or function should have just one reason to change.  How do we accomplish this? By developing small service classes with enclosed objectives.  What is it that we want to accomplish through this strategy?   More cohesion and less resistance to change. Allow the composition of classes (or class injection) which deserves a extended post in this blog. Avoid duplicity and copy-pasting portions of code. Now, that seems fairly simple but, as with any theoretical principle, the problem is usually visualizing with an example what the theory is suggesting and, even more than that, in which cases should we apply this theory. Of course, it's not the same developing a small online shop for a cousin who produces and sells hand made costume jewelry, than developing  an a...
    Read more

    Symfony HTTP client

     I am currently developing a very simple app which offers you the possibility to create question-answer flipping cards, creating thus some kind of funny Trivia to practice on any topic you want to apply it to. As a user, you create first the question-aswear entities which also include  category field, and then you can practice them in the playground area, which shows you the question on a hoverable flipping card. It also offers you a textearea which disables 60 seconds after you start typing on it, so that you can write down your answer before actually flipping the card and getting to see the correct one.  In this app, though simple, I wanted to keep a client-web service architecture from the very beginning. The web client contains the views and communicates with the API, which contains the data through Ajax calls. This was working consistently so far. An example of the creation and saving of new question-answer items is: When I press on "Create new question" button, I am...
    Read more

    Inheritance: Abstract classes and interfaces

    What is inheritance? It's a programming principle used in the PHP object model which allows a class (child) to inherit another class' (parent) protected or public methods, properties and constants, retaining the parent's original functionality, unless these are overriden by the child class. What is an abstract class? A class that contains at least one abstract method, which means only the signature of the method is defined. For example: abstract Class Parent { abstract protected function defineMyFunction (). } Class Child extends Parent {      protected function defineMyFunction () {           return "I am an abstract function in my Parent class" ;      } } As childish as this example might seem , it quite easily represents the aforementioned definition. When a  class (or child class) extends from an abstract class (or parent class), it must define all methods declared as abstract. In fact, if you are using an IDE...
    Read more