Programming Terms

There are various acronyms that crop up when discussing databases, code and approaches to programming:

  • ACID. ACID is a term usually used in the database world and relates to a transaction or unit of work. It stands for:
    • Atomicity which means that if a transaction consists of multiple statements all must complete for the entire transaction to be complete otherwise the data must remain in its original state.
    • Consistency which means that a transaction cannot leave a database in an invalid state.
    • Isolation which means that even if a transaction runs concurrently with another one it should leave the data the same as it would have done if the transactions had run sequentially
    • Durability which means that once a transaction has completed it stays that way.
  • DRY. DRY stands for Don’t Repeat Yourself which refers to reducing repetition in code and databases by using abstractions and normalisation. 
  • SOLID. SOLID is a term referring to making software that is easier to understand, maintain and adapt. It stands for:
    • Single responsibility principle which means that every module or class should be responsible for one element within the system
    • Open / Closed principle which means that classes, modules and functions should be open for extension but closed for modification. Effectively this means we should use inheritance to add additional logic or functionality.
    • Liskov substitution principle which means, amongst other examples, that we should override a method rather than replace it with a differently named one. So if we have a subclass then anywhere in the code the subclass should be capable of being replaced by an instance of the base class.
    • Interface segregation principle which means that you should not add additional methods to an existing interface. If additional methods are required create another interface and then the concrete class should implement both interfaces.
    • Dependency inversion principle which means high level modules should not depend on low level modules, they should both depend on abstractions and abstractions should not depend on details. As an example this means that in one class we should not create a concrete implementation of another class, for example if we create a TextLogger class within a controller we should actually refer to an ILogger object and then pass through the TextLogger in the constructor of the controller. That way in future we could use an EmailLogger class instead without having to update the controller.