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):