updates

Author: Sean-Bradley

abstract_factory/README.md

@@ -48,10 +48,6 @@ python ./abstract_factory/abstract_factory_concept.py
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- An example use case may be that you have a furniture shop front. You sell many different kinds of furniture. You sell chairs and tables. And they are manufactured at different factories using different unrelated processes that are not important for your concern. You only need the factory to deliver.
-
-You can create an extra module called `FurnitureFactory`, to handle the chair and table factories, thus removing the implementation details from the client. -->
-
 ## Abstract Factory Example UML Diagram
 
 See this UML diagram of an Abstract Furniture Factory implementation that returns chairs and tables.

adapter/README.md

@@ -50,12 +50,6 @@ The Adapter is used when you have an existing interface that doesn't directly ma
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- In this concept source code, there are two classes, `ClassA` and `ClassB`, with different method signatures. Let's consider that `ClassA` provides the most compatible and preferred interface for the client.
-
-I can create objects of both classes in the client and it works. But before using each objects method, I need to do a conditional check to see which type of class it is that I am calling since the method signatures are different.
-
-It means that the client is doing extra work. Instead, I can create an Adapter interface for the incompatible `ClassB`, that reduces the need for the extra conditional logic. -->
-
 ## Output
 
 ``` bash
@@ -70,15 +64,6 @@ method B
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- The example client can manufacture a **Cube** using different tools. Each solution is invented by a different company.
-The client user interface manages the Cube product by indicating the **width**, **height** and **depth**. This is compatible with the company A that produces the Cube tool, but not the company B that produces their own version of the Cube tool that uses a different interface with different parameters. 
-
-In this example, the client will re-use the interface for company A's Cube and create a compatible Cube from company B. 
-
-An adapter will be needed so that the same method signature can be used by the client without the need to ask company B to modify their Cube tool for our specific domains use case.
-
-My imaginary company needs to use both cube suppliers since there is a large demand for cubes and when one supplier is busy, I can then ask the other supplier. -->
-
 ## Example UML Diagram
 
 ![Adapter Pattern in Context](/img/adapter_example.svg)

bridge/README.md

@@ -67,12 +67,6 @@ The implementer part of a Bridge, can have one or more possible implementations
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- In the concept demonstration code, imagine that the classes were tightly coupled. The concrete class would print out some text to the console.
-
-After abstracting the class along a common ground, it is now more versatile. The implementation and has been separated from the abstraction and now it can print out the same text in two different ways.
-
-The befit now is that each refined abstraction and implementer can now be worked on independently without affecting the other implementations. -->
-
 ## Output
 
 ``` bash
@@ -87,16 +81,6 @@ c
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- In this example, I draw a square and a circle. Both of these can be categorized as shapes.
-
-The shape is set up as the abstraction interface. The refined abstractions, `Square` and `Circle` , implement the `IShape` interface.
-
-When the Square and Circle objects are created, they are also assigned their appropriate implementers being `SquareImplementer` and `CircleImplementer` .
-
-When each shape's `draw` method is called, the equivalent method within their implementer is called.
-
-The Square and Circle are bridged and each implementer and abstraction can be worked on independently. -->
-
 ## Example UML Diagram
 
 ![Bridge Pattern in Context](/img/bridge_example.svg)

builder/README.md

@@ -40,10 +40,6 @@ The Builder and Factory patterns are very similar in the fact they both instanti
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- 1. Client creates the **Director**.
-2. The Client calls the Directors `construct()` method that manages each step of the build process.
-3. The Director returns the product to the client or alternatively could also provide a method for the client to retrieve it later. -->
-
 ## Output
 
 ``` bash
@@ -55,14 +51,6 @@ python ./builder/builder_concept.py
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- Using the Builder Pattern in the context of a House Builder. 
-
-There are multiple directors that can create their own complex objects.
-
-Note that in the `IglooDirector` class, not all of the methods of the `HouseBuilder` were called. 
-
-The builder can construct complex objects in any order and include/exclude whichever parts it likes. -->
-
 ## Example UML Diagram
 
 ![Builder Pattern in Context](/img/builder_example.svg)

chain_of_responsibility/README.md

@@ -41,8 +41,6 @@ The chain that the object will pass through is normally dynamic at runtime, alth
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- In this concept code, a chain is created with a default first successor. A number is passed to a successor, which then does a random test, and depending on the result will modify the number and then pass it onto the next successor. The process is randomized and will end at some point when there are no more successors designated. -->
-
 ## Output
 
 ``` bash
@@ -61,13 +59,6 @@ Finished result = -1.5
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- 
-In the ATM example below, the chain is hard coded in the client first to dispense amounts of £50s, then £20s and then £10s in order. 
-
-This default chain order helps to ensure that the minimum number of notes will be dispensed. Otherwise, it might dispense 5 x £10 when it would have been better to dispense 1 x £50.
-
-Each successor may be re-called recursively for each denomination depending on the value that was requested for withdrawal. -->
-
 ## Example UML Diagram
 
 ![Chain of Responsibility Design Pattern](/img/chain_of_responsibility_example.svg)

command/README.md

@@ -53,16 +53,6 @@ Uses:
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- The Client instantiates a Receiver that accepts certain commands.
-
-The Client then creates two Command objects that will call one of the specific commands on the Receiver.
-
-The Client then creates an Invoker, E.g., a user interface with buttons, and registers both Commands into the Invokers dictionary of commands.
-
-The Client doesn't call the receivers commands directly, but the via the Invoker, which then calls the registered Command objects `execute()` method.
-
-This abstraction between the invoker, command and receiver, allows the Invoker to add extra functionality such as history, replay, UNDO/REDO, logging, alerting and any other useful things that may be required. -->
-
 ## Output
 
 ``` bash
@@ -77,14 +67,6 @@ Executing Command 2
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- This will be a smart light switch. 
-
-This light switch will keep a history of each time one of its commands was called. 
-
-And it can replay its commands. 
-
-A smart light switch could be extended in the future to be called remotely or automated depending on sensors. -->
-
 ## Example UML Diagram
 
 ![The Command Pattern UML Diagram](/img/command_example.svg)

composite/README.md

@@ -42,16 +42,6 @@ Examples of using the Composite Design Pattern can be seen in a file
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- In this concept code, two leaves are created, `LEAF_A` and `LEAF_B`, and two composites are created, `COMPOSITE_1` and `COMPOSITE_2` .
-
-`LEAF_A` is attached to `COMPOSITE_1` .
-
-Then I change my mind and attach `LEAF_A` to `COMPOSITE_2` .
-
-I then attach `COMPOSITE_1` to `COMPOSITE_2` .
-
-`LEAF_B` is not attached to composites. -->
-
 ## Output
 
 ``` bash
@@ -72,14 +62,6 @@ COMPOSITE_2     id:2050574298128
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- Demonstration of a simple in memory hierarchal file system.
-
-A root object is created that is a composite.
-
-Several files (leaves) are created and added to the root folder.
-
-More folders (composites) are created, and more files are added, and then the hierarchy is reordered. -->
-
 ## Composite Example UML Diagram
 
 ![Composite Pattern Use Case UML Diagram](/img/composite_example.svg)

decorator/README.md

@@ -51,14 +51,6 @@ Decorator Method(Component Method)
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- Let's create a custom class called `Value` that will hold a number. 
-
-Then add decorators that allow addition (`Add`) and subtraction (`Sub`) to a number (`Value`).
-
-The `Add` and `Sub` decorators can accept integers directly, a custom `Value` object or other `Add` and `Sub` decorators.
-
-`Add`, `Sub` and `Value` all implement the `IValue` interface and can be used recursively. -->
-
 ## Example UML Diagram
 
 ![Decorator Pattern in Context](/img/decorator_example.svg)

facade/README.md

@@ -43,10 +43,6 @@ B
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- This is an example of a game engine API. The facade layer is creating one streamlined interface consisting of several methods from several larger API backend systems. 
-
-The client could connect directly to each subsystems API and implement its authentication protocols, specific methods, etc. While it is possible, it would be quite a lot of consideration for each of the development teams, so the facade API unifies the common methods which becomes much less overwhelming for each new the client developer to integrate into. -->
-
 ## Example UML Diagram
 
 ![Facade Example UML Diagram](/img/facade_example.svg)

factory/README.md

@@ -50,12 +50,6 @@ The Factory pattern is really about adding that extra abstraction between the ob
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- In this concept example, the client wants an object named `b`
-
-Rather than creating `b` directly in the client, it asks the creator (factory) for the object instead. 
-
-The factory finds the relevant class using some kind of logic from the attributes of the request. It then asks the subclass to instantiate the new object which it then returns as a reference back to the client asking for it. -->
-
 ## Output
 
 ``` bash
@@ -67,12 +61,6 @@ ConcreteProductB
 
 *...Refer to Book or Videos for extra content.*
 
-<!-- An example use case is a user interface where the user can select from a menu of items, such as chairs. 
-
-The user has been given a choice using some kind of navigation interface, and it is unknown what choice, or how many the user will make until the application is actually running and the user starts using it.
-
-So, when the user selected the chair, the factory then takes some property involved with that selection, such as an ID, Type or other attribute and then decides which relevant subclass to instantiate in order to return the appropriate object. -->
-
 ## Factory Example UML Diagram
 
 ![Chair Factory](/img/factory_example.svg)