Introduced by Alistair Cockburn in 2005 as an alternative to the traditional layered architecture, the Ports & Adapters architecture clearly separates core logic from the input and output infrastructure, dividing the system into loosely-coupled interchangeable components. Throughout the years, it grew in popularity to become one of the most widely recognized types of software architecture.
Category: Clean code
A low code coverage indicates that code is not well tested and therefore unsafe to work with. Unfortunately, a high code coverage does not give certainty that the tests are well written. Mutation testing promises to give us some of that certainty, by checking how well our tests hold up to changes in code behavior.
The Interface Segregation Principle represents the “I” in SOLID and states that no client should be forced to depend on methods it does not use. The easiest way to achieve compliance is to to split large interfaces which are not specific to a single client into smaller, more specific ones and let the clients choose which ones to depend on.
The Liskov Substitution Principle, introduced by Barbara Liskov, represents the “L” in SOLID. It states that every implementation of a class should be replaceable with an implementation of any class that extends it. In other words, every instance of a parent class should be replaceable by any instance of its child classes so that the application continues to work.
The Open/Closed Principle represents the “O” in SOLID. In the words of Bertrand Meyer (who originated the term), it states that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification“. What it means is that one should be able to extend the behavior of an entity without modifying its code.
The Single Responsibility Principle represents the “S” in SOLID. It means that a software module should only have one responsibility – in other words, there should never be more than one reason to modify that module (excluding, of course, refactoring and bug fixes). The responsibility of a module should be entirely encapsulated within that module and all services within it should be narrowly aligned with it.