updates

Author: Sean-Bradley

abstract_factory/big_chair.py

@@ -3,7 +3,7 @@
 
 
 class BigChair(IChair):  # pylint: disable=too-few-public-methods
-    "The Big Chair Concrete Class which implements the IChair interface"
+    "The Big Chair Concrete Class that implements the IChair interface"
 
     def __init__(self):
         self._height = 80

abstract_factory/factory_a.py

@@ -13,7 +13,7 @@ def create_object():
 
 
 class ConcreteProductA(IProduct):
-    "A Concrete Class which implements the IProduct interface"
+    "A Concrete Class that implements the IProduct interface"
 
     def __init__(self):
         self.name = "ConcreteProductA"
@@ -23,7 +23,7 @@ def create_object(self):
 
 
 class ConcreteProductB(IProduct):
-    "A Concrete Class which implements the IProduct interface"
+    "A Concrete Class that implements the IProduct interface"
 
     def __init__(self):
         self.name = "ConcreteProductB"
@@ -33,7 +33,7 @@ def create_object(self):
 
 
 class ConcreteProductC(IProduct):
-    "A Concrete Class which implements the IProduct interface"
+    "A Concrete Class that implements the IProduct interface"
 
     def __init__(self):
         self.name = "ConcreteProductC"

abstract_factory/factory_b.py

@@ -13,7 +13,7 @@ def create_object():
 
 
 class ConcreteProductA(IProduct):
-    "A Concrete Class which implements the IProduct interface"
+    "A Concrete Class that implements the IProduct interface"
 
     def __init__(self):
         self.name = "ConcreteProductA"
@@ -23,7 +23,7 @@ def create_object(self):
 
 
 class ConcreteProductB(IProduct):
-    "A Concrete Class which implements the IProduct interface"
+    "A Concrete Class that implements the IProduct interface"
 
     def __init__(self):
         self.name = "ConcreteProductB"
@@ -33,7 +33,7 @@ def create_object(self):
 
 
 class ConcreteProductC(IProduct):
-    "A Concrete Class which implements the IProduct interface"
+    "A Concrete Class that implements the IProduct interface"
 
     def __init__(self):
         self.name = "ConcreteProductC"

adapter/README.md

@@ -37,7 +37,7 @@ In this concept source code, there are two classes, `ClassA` and `ClassB`, with
 
 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`, which reduces the need for the extra conditional logic.
+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
 
@@ -136,7 +136,7 @@ You can use it in logical statements as I do in [/adapter/adapter_concept.py](/a
 
 The time module provides time related functions, most notably in my case, the current epoch (ticks) since `January 1, 1970, 00:00:00 (UTC)` .
 
-The `time` module provides many options which are outlined in more detail at [https://docs.python.org/3/library/time.html](https://docs.python.org/3/library/time.html)
+The `time` module provides many options that are outlined in more detail at [https://docs.python.org/3/library/time.html](https://docs.python.org/3/library/time.html)
 
 In [/adapter/cube_a.py](/adapter/cube_a.py), I check the `time.time()` at various intervals to compare how long a task took. 
 

bridge/README.md

@@ -6,7 +6,7 @@ The **Bridge pattern** is similar to the [Adapter](/adapter) pattern except in t
 
 The Bridge is an approach to refactor already existing code, whereas the Adapter creates an interface on top of existing code through existing available means without refactoring any existing code or interfaces.
 
-The motivation for converting your code to the Bridge pattern is that it may be tightly coupled. There is logic and abstraction close together which is limiting your choices in how you can extend your solution in the way that you need.
+The motivation for converting your code to the Bridge pattern is that it may be tightly coupled. There is logic and abstraction close together that is limiting your choices in how you can extend your solution in the way that you need.
 
 E.g., you may have one Car class, that produces a very nice car. But you would like the option of varying the design a little, or outsourcing responsibility of creating the different components.
 
@@ -152,5 +152,5 @@ PS> python
 
 * Use when you want to separate a solution where the abstraction and implementation may be tightly coupled and you want to break it up into smaller conceptual parts.
 * Once you have added the bridge abstraction, you should be able to extend each side of it separately without breaking the other.
-* Also, once the bridge abstraction exists, you can more easily create extra concrete implementations for other similar products which may also happen to be split across similar conceptual lines.
+* Also, once the bridge abstraction exists, you can more easily create extra concrete implementations for other similar products that may also happen to be split across similar conceptual lines.
 * The Bridge pattern is similar to the adapter pattern except in the intent that you developed it. The bridge is an approach to refactor already existing code, whereas the adapter adapts to the existing code through its existing interfaces and methods without changing the internals.

builder/README.md

@@ -9,7 +9,7 @@ The Builder Pattern tries to solve,
 * How can a class create different representations of a complex object?
 * How can a class that includes creating a complex object be simplified?
 
-The Builder and Factory patterns are very similar in the fact they both instantiate new objects at runtime. The difference is when the process of creating the object is more complex, so rather than the Factory returning a new instance of `ObjectA`, it calls the builders director constructor method `ObjectA.construct()` which goes through a more complex construction process involving several steps. Both return an Object/Product.
+The Builder and Factory patterns are very similar in the fact they both instantiate new objects at runtime. The difference is when the process of creating the object is more complex, so rather than the Factory returning a new instance of `ObjectA`, it calls the builders director constructor method `ObjectA.construct()` that goes through a more complex construction process involving several steps. Both return an Object/Product.
 
 ## Terminology
 
@@ -25,7 +25,7 @@ The Builder and Factory patterns are very similar in the fact they both instanti
 ## Source Code
 
 1. Client creates the **Director**.
-2. The Client calls the Directors `construct()` method which manages each step of the build process.
+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

chain_of_responsibility/README.md

@@ -111,9 +111,9 @@ See PEP-3111 : [https://www.python.org/dev/peps/pep-3111/](https://www.python.or
 ## Summary
 
 * The object will propagate through the chain until fully processed.
-* The object does not know which successor or how many will process it.
+* The object does not know that successor or how many will process it.
 * The next successor in the chain is chosen dynamically at runtime depending on logic from the current successor.
-* Successors implement a common interface which makes them work independently of each other, so that they can be used recursively or possibly in a different order.
+* Successors implement a common interface that makes them work independently of each other, so that they can be used recursively or possibly in a different order.
 * A user wizard, or dynamic questionnaire are other common use cases for the chain of responsibility pattern.
 * The chain of responsibility and [Composite](/composite) patterns are often used together because of their similar approach to hierarchy and possible re-ordering. The Composites parent/child relationship is set in an object's property by a process outside of the class and can be changed at runtime. While with the Chain of Responsibility, each successor runs a dynamic algorithm internally, to decide which successor is next in line.
 * The chain can be fully dynamically created, or it can be set as a default with the possibility of changing at runtime.

coding-conventions.md

@@ -46,7 +46,7 @@ The code styling in this repository is formatted using mostly PEP8 styling recom
 * **UPPER_CASE** : Constants will be defined using UPPER_CASE naming style.
 * **PascalCase** : Class names will use PascalCase naming style
 * **snake_case** : For variables names, method names and method arguments.
-* **Docstrings** : Classes and methods contain extra documentation which is descriptive text enclosed in " or """ for multiline strings.
+* **Docstrings** : Classes and methods contain extra documentation that is descriptive text enclosed in " or """ for multiline strings.
 * **_leading_underscore** : Use a leading underscore to indicate variables that should be considered as private class variables.
 
 See PEP-0008 : [https://www.python.org/dev/peps/pep-0008/](https://www.python.org/dev/peps/pep-0008/)

command/README.md

@@ -4,7 +4,7 @@
 
 The **Command** pattern is a behavioral design pattern, in which an abstraction exists between an object that invokes a command, and the object that performs it.
 
-E.g., a button will call the **Invoker**, which will call a pre-registered **Command**, which the **Receiver** will perform.
+E.g., a button will call the **Invoker**, that will call a pre-registered **Command**, that the **Receiver** will perform.
 
 A Concrete Class will delegate a request to a command object, instead of implementing the request directly.
 
@@ -28,18 +28,18 @@ Uses:
 
 * **Receiver**: The object that will receive and execute the command.
 * **Invoker**: The object that sends the command to the receiver. E.g., A button.
-* **Command Object**: Itself, an object, which implements an execute, or action method, and contains all required information to execute it.
-* **Client**: The application or component which is aware of the Receiver, Invoker and Commands.
+* **Command Object**: Itself, an object, that implements an execute, or action method, and contains all required information to execute it.
+* **Client**: The application or component that is aware of the Receiver, Invoker and Commands.
 
 ## Command Pattern UML Diagram
 
 ![The Command Pattern UML Diagram](/img/command_concept.svg)
 
 ## Source Code
 
-The Client instantiates a Receiver which accepts certain commands that do things.
+The Client instantiates a Receiver that accepts certain commands.
 
-The Client then creates two Command objects which will call one of the specific commands on the Receiver.
+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.
 

command/command_concept.py

@@ -3,11 +3,11 @@
 
 
 class ICommand(metaclass=ABCMeta):  # pylint: disable=too-few-public-methods
-    "The command interface, which all commands will implement"
+    "The command interface, that all commands will implement"
     @staticmethod
     @abstractmethod
     def execute():
-        "The required execute method which all command objects will use"
+        "The required execute method that all command objects will use"
 
 
 class Invoker:
@@ -43,7 +43,7 @@ def run_command_2():
 
 
 class Command1(ICommand):  # pylint: disable=too-few-public-methods
-    """A Command object, which implements the ICommand interface and
+    """A Command object, that implements the ICommand interface and
     runs the command on the designated receiver"""
 
     def __init__(self, receiver):
@@ -54,7 +54,7 @@ def execute(self):
 
 
 class Command2(ICommand):  # pylint: disable=too-few-public-methods
-    """A Command object, which implements the ICommand interface and
+    """A Command object, that implements the ICommand interface and
     runs the command on the designated receiver"""
 
     def __init__(self, receiver):

command/interface_switch.py

@@ -1,11 +1,11 @@
-"The switch interface, which all commands will implement"
+"The switch interface, that all commands will implement"
 from abc import ABCMeta, abstractmethod
 
 
 class ISwitch(metaclass=ABCMeta):  # pylint: disable=too-few-public-methods
-    "The switch interface, which all commands will implement"
+    "The switch interface, that all commands will implement"
 
     @staticmethod
     @abstractmethod
     def execute():
-        "The required execute method which all command objects will use"
+        "The required execute method that all command objects will use"

command/switch_off_command.py

@@ -1,5 +1,5 @@
 """
-A Command object, which implements the ISwitch interface and runs the
+A Command object, that implements the ISwitch interface and runs the
 command on the designated receiver
 """
 from interface_switch import ISwitch

command/switch_on_command.py

@@ -1,5 +1,5 @@
 """
-A Command object, which implements the ISwitch interface and runs the
+A Command object, that implements the ISwitch interface and runs the
 command on the designated receiver
 """
 from interface_switch import ISwitch

composite/README.md

@@ -56,7 +56,7 @@ COMPOSITE_2     id:2050574298128
 
 Demonstration of a simple in memory hierarchal file system.
 
-A root object is created which is a composite.
+A root object is created that is a composite.
 
 Several files (leaves) are created and added to the root folder.
 

composite/folder.py

@@ -1,4 +1,4 @@
-"A Folder, which acts as a composite."
+"A Folder, that acts as a composite."
 from interface_component import IComponent
 
 

decorator/README.md

@@ -34,7 +34,7 @@ Decorator Method(Component Method)
 
 ## Example Use Case
 
-Let's create a custom class called `Value` which will hold a number. 
+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`).
 

decorator/add.py

@@ -8,7 +8,7 @@ class Add(IValue):
 
     def __init__(self, val1, val2):
         # val1 and val2 can be int or the custom Value
-        # object which contains the `value` attribute
+        # object that contains the `value` attribute
         val1 = getattr(val1, 'value', val1)
         val2 = getattr(val2, 'value', val2)
         self.value = val1 + val2

decorator/sub.py

@@ -8,7 +8,7 @@ class Sub(IValue):
 
     def __init__(self, val1, val2):
         # val1 and val2 can be int or the custom Value
-        # object which contains the `value` attribute
+        # object that contains the `value` attribute
         val1 = getattr(val1, 'value', val1)
         val2 = getattr(val2, 'value', val2)
         self.value = val1 - val2

facade/README.md

@@ -165,5 +165,5 @@ Found 2 errors in 2 files (checked 1 source file)
 * You want to layer your subsystems into an abstraction that is easier to understand.
 * [Abstract Factory](/abstract_factory) and Facade can be considered very similar. An Abstract Factory is about creating in interface over several creational classes of similar objects, whereas the Facade is more like an API layer over many creational, structural and/or behavioral patterns. 
 * The [Mediator](/mediator) is similar to the Facade in the way that it abstracts existing classes. The Facade is not intended to modify, load balance or apply any extra logic. A subsystem does not need to consider that existence of the facade, it would still work without it.
-* A Facade is a minimal interface which could also be implemented as a [Singleton](/singleton).
+* A Facade is a minimal interface that could also be implemented as a [Singleton](/singleton).
 * A Facade is an optional layer that does not alter the subsystem. The subsystem does not need to know about the Facade, and could even be used by many other facades created for different audiences.

factory/README.md

@@ -77,7 +77,7 @@ ABCMeta refers to **A**bstract **B**ase **C**lasses.
 
 The benefits of using ABCMeta classes to create abstract classes is that your IDE and Pylint will indicate to you at development time whether your inheriting classes conform to the class definition that you've asked them to.
 
-Abstract classes are not instantiated directly in your scripts, but instead inherited by subclasses that will provide the implementation code for the abstract methods. E.g., you don't create `IChair`, but you create `SmallChair` which implemented the methods described in the `IChair` interface.
+Abstract classes are not instantiated directly in your scripts, but instead inherited by subclasses that will provide the implementation code for the abstract methods. E.g., you don't create `IChair`, but you create `SmallChair` that implemented the methods described in the `IChair` interface.
 
 An abstract method is a method that is declared, but contains no implementation. The implementation happens at the class that inherits the abstract class.
 

factory/factory_concept.py

@@ -13,7 +13,7 @@ def create_object():
 
 
 class ConcreteProductA(IProduct):
-    "A Concrete Class which implements the IProduct interface"
+    "A Concrete Class that implements the IProduct interface"
 
     def __init__(self):
         self.name = "ConcreteProductA"
@@ -23,7 +23,7 @@ def create_object(self):
 
 
 class ConcreteProductB(IProduct):
-    "A Concrete Class which implements the IProduct interface"
+    "A Concrete Class that implements the IProduct interface"
 
     def __init__(self):
         self.name = "ConcreteProductB"
@@ -33,7 +33,7 @@ def create_object(self):
 
 
 class ConcreteProductC(IProduct):
-    "A Concrete Class which implements the IProduct interface"
+    "A Concrete Class that implements the IProduct interface"
 
     def __init__(self):
         self.name = "ConcreteProductC"

flyweight/README.md

@@ -57,7 +57,7 @@ In this example, I create a dynamic table with 3 rows and 3 columns each. The co
 
 The letters are the flyweights and only a code indicating the letter is stored. The letters and numbers are shared many times.
 
-The columns are the contexts and they pass the extrinsic vales describing the combination of letters, the justification left, right or center, and the width of the table column which is then used for the space padding.
+The columns are the contexts and they pass the extrinsic vales describing the combination of letters, the justification left, right or center, and the width of the table column that is then used for the space padding.
 
 ## Example UML Diagram
 

flyweight/column.py

@@ -1,4 +1,4 @@
-"A Column which is used in a Row"
+"A Column that is used in a Row"
 from flyweight_factory import FlyweightFactory
 
 class Column():  # pylint: disable=too-few-public-methods

flyweight/flyweight.py

@@ -1,8 +1,8 @@
-"The Flyweight which contains an intrinsic value called code"
+"The Flyweight that contains an intrinsic value called code"
 
 
 class Flyweight():  # pylint: disable=too-few-public-methods
-    "The Flyweight which contains an intrinsic value called code"
+    "The Flyweight that contains an intrinsic value called code"
 
     def __init__(self, code: int) -> None:
         self.code = code

interpreter/README.md

@@ -55,7 +55,7 @@ I then construct the AST manually, by adding a
 3. Non-Terminal `Add` row containing the previous Non-Terminal row and the `7`
 4. Non-Terminal `Subtract` row containing the previous Non-Terminal row and the `2`
 
-The AST root becomes the final row that was added, and then I can run the `interpret()` method on that which will interpret the full AST recursively because each AST row references the row above it.
+The AST root becomes the final row that was added, and then I can run the `interpret()` method on that, which will interpret the full AST recursively because each AST row references the row above it.
 
 ## Output