Update SOLID.md

Readability improvements
Removed a few areas of clutter

Added spacing
removed Headers from the listing.
Added a note for an important section.
Added " Example " text and modifications for code block areas.

Author: VerzatileDev

docs/Concepts/SOLID.md

@@ -11,36 +11,51 @@ has_children: false
 
 ## What is SOLID?
 Not just a state of matter!
-SOLID is an acronym that represents a set of principles for writing maintainable and scalable object-oriented code. These principles were introduced by Robert C. Martin, and are considered fundamental guidelines for software development. Each letter in SOLID represents a different principle.
+SOLID is an acronym that represents a set of principles for writing maintainable and scalable object-oriented code. These principles were introduced by Robert C. Martin, and are considered fundamental guidelines for software development.
 
-### 1) S = Single Responsibility Principle (SRP):
-- A class should have only one reason to change, meaning it should have only one responsibility or job.
-- This principle encourages the organization of code by ensuring that each class or module has a clear and specific purpose.
+---
+
+### Each letter in SOLID represents a different principle:
+
+<br>
+
+1. **S = Single Responsibility Principle (SRP):**
+
+    - A class should have only one reason to change, meaning it should have only one responsibility or job.
+    - This principle encourages the organization of code by ensuring that each class or module has a clear and specific purpose.
 
-### 2) O = Open/Closed Principle (OCP):
-- Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
-- This means that you should be able to add new functionality without altering existing code.
+2. **O = Open/Closed Principle (OCP):**
 
-### 3) L = Liskov Substitution Principle (LSP):
-- Subtypes should be substitutable for their base types without altering the correctness of the program.
-- In simpler terms, objects of a superclass should be replaceable with objects of a subclass without affecting the functionality of the program.
+    - Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
+    - This means that you should be able to add new functionality without altering existing code.
 
-### 4) I = Interface Segregation Principle (ISP):
-- Clients should not be forced to depend on interfaces they do not use.
-- This principle suggests that it is better to have small, specific interfaces rather than a large, all-encompassing one. Clients should not be forced to implement interfaces they don't need.
+3. **L = Liskov Substitution Principle (LSP):**
 
-### 5) D = Dependency Inversion Principle (DIP):
-- High-level modules should not depend on low-level modules; both should depend on abstractions. Additionally, abstractions should not depend on details; details should depend on abstractions.
-- This principle encourages the use of abstractions (such as interfaces or abstract classes) to decouple high-level modules from low-level modules, promoting flexibility and maintainability.
+    - Subtypes should be substitutable for their base types without altering the correctness of the program.
+    - In simpler terms, objects of a superclass should be replaceable with objects of a subclass without affecting the functionality of the program.
 
-Applying SOLID principles in your code can lead to a more modular, flexible, and maintainable codebase. It helps reduce the impact of changes, makes the code easier to understand, and facilitates the addition of new features. While strict adherence to all the principles may not always be practical in every situation, striving to follow them can significantly improve the quality of your software design.
+4. **I = Interface Segregation Principle (ISP):**
 
------------------------------------------------------------------------
+    - Clients should not be forced to depend on interfaces they do not use.
+    - This principle suggests that it is better to have small, specific interfaces rather than a large, all-encompassing one. Clients should not be forced to implement interfaces they don't need.
+
+5. **D = Dependency Inversion Principle (DIP):**
+
+    - High-level modules should not depend on low-level modules; both should depend on abstractions. Additionally, abstractions should not depend on details; details should depend on abstractions.
+    - This principle encourages the use of abstractions (such as interfaces or abstract classes) to decouple high-level modules from low-level modules, promoting flexibility and maintainability.
+
+<br>
+
+{: .note }
+By Applying `SOLID` principles in your code leads to a more modular, flexible, and maintainable codebase. Reducing the impact on changes, code becomes easier to understand, facilitates the addition of new features. While strict adherence to all the principles may not always be practical in every situation, striving to follow them can significantly improve the quality of your software design.
+
+---
 
 ## Examples
 
 Here are some simple example problems that explore making a coffee. Here is some example "Problem" code:
 
+{: .code title="Example:"}
 ```cpp
 #include <iostream>
 
@@ -77,14 +92,15 @@ public:
 };
 ```
 
------------------------------------------------------------------------
+---
 
 ### Single Responsibility Principle (SRP):
 
 The initial CoffeeMaker class is responsible for multiple tasks such as grinding coffee beans, brewing coffee, pouring it into a cup, and adding condiments. That's way too many functions for just one class! This violated the SRP because the class had more than one reason to change — any change in the coffee-making process could impact the entire class.
 
 How can we solve this? Well, by breaking down and applying Single Responsibilities to each class element, we reduce the need to mess with the whole class. 
 
+{: .code title="Example:"}
 ```cpp
 #include <iostream>
 
@@ -145,12 +161,13 @@ public:
 
 To adhere to SRP, the CoffeeMaker class is now refactored into separate classes, each responsible for a specific aspect of coffee making (grinding, brewing, pouring, and adding condiments). This separation of concerns makes each class focused on a single responsibility. The CoffeeMaker class then orchestrates these components to make coffee. This way, if there's a change in the coffee grinding process (say we use a different kind of bean), for example, it only affects the CoffeeGrinder class!
 
------------------------------------------------------------------------
+---
 
 ### Open/Closed Principle (OCP):
 
 The initial design was not closed for modification, especially when introducing new types of coffee. Adding a new coffee type required modifying the existing CoffeeMaker class.
 
+{: .code title="Example:"}
 ```cpp
 class CoffeeMaker 
 {
@@ -175,7 +192,7 @@ public:
 
 By using polymorphism and creating abstract classes/interfaces (CoffeeMaker), we open the door for extension. Instead, by using Inheritance and Polymorphism, we can now add a "LatteMaker" and "CappucinoMaker" class without modifying the existing CoffeeMaker class code. This adheres to the OCP, making the system more flexible and extensible.
 
------------------------------------------------------------------------
+---
 
 ### Liskov Substitution Principle (LSP):
 
@@ -185,13 +202,14 @@ By ensuring that derived classes adhere to the same interface as the base class
 
 In this example, we solved this just by making `makeCoffee()` virtual and making sure the child classes override this function, but it can get more complex than this!
 
------------------------------------------------------------------------
+---
 
 ### Interface Segregation Principle (ISP):
 
 The initial CoffeeMaker class had methods for grinding coffee beans and adding condiments, which might not be applicable to all types of coffee.
 We can solve this by creating separate interfaces for different aspects of coffee making.
 
+{: .code title="Example:"}
 ```cpp
 class CoffeeGrinder 
 {
@@ -227,12 +245,13 @@ public:
 
 By creating separate interfaces (CoffeeGrinder and CondimentAdder), each coffee maker class can implement only the interfaces it needs. This adheres to the ISP, ensuring that no class is forced to implement methods it doesn't use, leading to more modular and focused interfaces.
 
------------------------------------------------------------------------
+---
 
 ### Dependency Inversion Principle (DIP):
 
 The initial CoffeeMaker class had direct dependencies on concrete classes (CoffeeGrinder, CoffeeBrewer, CoffeePourer, CondimentAdder), making it hard to change or extend the behavior of these components without modifying the CoffeeMaker class.
 
+{: .code title="Example:"}
 ```cpp
 // Depend on abstractions (interfaces) rather than concrete implementations.
 class CoffeeMaker 
@@ -268,14 +287,13 @@ private:
 
 By depending on abstractions (interfaces) instead of concrete implementations, the CoffeeMaker class becomes more flexible. This adheres to DIP, allowing for easy substitution of components. For example, if a new and improved coffee grinder is introduced, it can be swapped without modifying the CoffeeMaker class.
 
------------------------------------------------------------------------
+---
 
 ### Conclusion
 
 In summary, the approach involved breaking down responsibilities, introducing abstractions/interfaces, and adhering to principles that promote flexibility, extensibility, and maintainability. Each SOLID principle addresses specific concerns, contributing to a more robust and scalable design. This is just a simple example, but there are times where this idea can get highly complex!
 
------------------------------------------------------------------------
+---
 
 #### Author: JDSherbert
 #### Published: 11/12/2023
-