Single Responsibility | Open Closed | Liskov Substitution | Interface Segregation | Dependency Inversion The Dependency Inversion Principle states that “Depend upon Abstractions. Do not depend upon concretions”. A good real world example of this is plug sockets around your house; any device you buy can be plugged into any socket in your house. You don’t have to buy new set of devices when you move house, and you don’t have to buy a new house for your devices!...
Interface Segregation Principle Single Responsibility | Open Closed | Liskov Substitution | Interface Segregation | Dependency Inversion Interface Segregation I find is often ignored, or people tend not to see the point in. Segregating your Interfaces is a very useful way of reducing compexity in your systems, and comes with a number of benefits, such as making mocking inputs easier, and making your objects smaller and simpler. So as usual, lets start off with an set of types which don’t adhere to the principle....
Liskov Substitution Principle Single Responsibility | Open Closed | Liskov Substitution | Interface Segregation | Dependency Inversion The Liskov Substitution Principle is states: If S is a sub-type of T, then objects of type T maybe replaced with objects of type S At face value, it means that a small class hierarchy like this: public class FileEntry { } public class DbFileEntry : FileEntry { } And a method which takes in a FileEntry, can be called like this:...
Open Closed Principle Single Responsibility | Open Closed | Liskov Substitution | Interface Segregation | Dependency Inversion The Open Closed Principle is one that I often find is miss-understood - how can something be open for extension, but closed for modification? A good example of this principle being implemented cropped up at work a while ago, we had a UI element which has a reusable grid, which gets populated with data based on a menu selection....
Single Responsibility Principle Single Responsibility | Open Closed | Liskov Substitution | Interface Segregation | Dependency Inversion SRP (Single Responsibility Principle) is something I hear a lot of developers agree is a good thing, but when I read their code, they violate it without realising, or don’t see the use in their particular case. A particularly prominent example I find in our code bases is Permissioning and Caching. These two requirements can often slip into classes slowly - especially if requirements are not clear, or change as the task progresses....