The SOLID principles

guides/agile/SOLID_Principles/Dependency_Inversion.md

@@ -0,0 +1,7 @@
+# Dependency Inversion
+
+The dependency inversion (DI) principle means that a high level function should not be dealing with the low level details.
+
+If you wanted to send an email when a delivery has been sent, maybe at the end of the SendDelivery method you would create an emailClient, then compose and send the email. However what if you wanted to send a text instead, or just use a different email client? You would need to re-write the code in the SendDelivery method.
+
+With DI the SendDelivery method could instead accept a MessageClient interface and could be provided the desired implementation. By doing this the code becomes more modular and allows for changes without modifying the code that uses it.

guides/agile/SOLID_Principles/Interface_Segregation.md

@@ -0,0 +1,7 @@
+# Interface Segregation
+
+Interface segregation states that anything that inherits from another type, isn't forced to depend on methods that are not used.
+
+For example there are different types of printers, some include scanners, fax functionality, some can even staple automatically, if all of this functionality was written into just one printer interface, printers that don't include these features would still need to handle the functions.
+
+Instead the printer interface should be split into a print interface, scanner interface etc.. by doing so a class can inherit only what it requires and nothing more.

guides/agile/SOLID_Principles/Liskov_Substitution.md

@@ -0,0 +1,11 @@
+# Liskov Substitution
+
+This one sounds a lot scarier than it is simply because it's named after Barbara Liskov who originally introduced the idea.
+
+This principle states that any subtype should be able to replace the parent without anything breaking.
+
+The clearest example of this is a shape class, the class contains width and height properties and a setWidth and setHeight methods.
+
+A Square and Rectangle class inherit from shape, for the rectangle class everything works as it has both a length and width and these can be changed independently.
+
+The square however only has size, it would be possible to create the square by just taking a size and setting the width and height to that same value, but if setWidth was called and changed the width value then the square would no longer represent a square. Because of this the shape and square classes violate the Liskov substitution principle.

guides/agile/SOLID_Principles/Open-Close.md

@@ -0,0 +1,7 @@
+# Open/Closed Principle
+
+The open closed principle states that a piece of software is open for extension but closed for modification.
+
+It's easy to see how extending a class with more functionality comes with little risk, as there is no pre-existing code that it's in use by there is nothing that could break.
+
+Any code that is used and working as expected if modified could lead to unknown errors in what was working code and if the project is a library any third party using the library could be faced with issues.

guides/agile/SOLID_Principles/Single_Responsibility.md

@@ -0,0 +1,7 @@
+# Single Responsibility Principle
+
+The single responsibility principle (SRP) is the first of the SOLID principles, a set of principles set out to help produce cleaner and more maintainable code.
+
+SRP simply means that any class, module, function... should only handle a single aspect of the program, for example if you have an add function that takes two number and returns the sum of those numbers, you would not expect it to output a file with the result.
+
+Similarly an Employee class shouldn't contain functions related to Warehouse stock as they are unrelated.