update intro to patterns

patterns/Iterator-uml.uxf

@@ -1,13 +1,13 @@
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <diagram program="umlet" version="14.2">
-  <zoom_level>10</zoom_level>
+  <zoom_level>12</zoom_level>
   <element>
     <id>UMLClass</id>
     <coordinates>
-      <x>210</x>
-      <y>180</y>
-      <w>190</w>
-      <h>90</h>
+      <x>24</x>
+      <y>24</y>
+      <w>228</w>
+      <h>108</h>
     </coordinates>
     <panel_attributes>&lt;&lt;interface&gt;&gt;
 Iterator&lt;T&gt;
@@ -19,10 +19,10 @@ next(): T</panel_attributes>
   <element>
     <id>UMLClass</id>
     <coordinates>
-      <x>210</x>
-      <y>310</y>
-      <w>190</w>
-      <h>70</h>
+      <x>24</x>
+      <y>180</y>
+      <w>228</w>
+      <h>84</h>
     </coordinates>
     <panel_attributes>ConcreteIterator
 --
@@ -33,21 +33,21 @@ next(): T</panel_attributes>
   <element>
     <id>Relation</id>
     <coordinates>
-      <x>300</x>
-      <y>260</y>
-      <w>30</w>
-      <h>70</h>
+      <x>132</x>
+      <y>120</y>
+      <w>36</w>
+      <h>84</h>
     </coordinates>
     <panel_attributes>lt=&lt;&lt;.</panel_attributes>
     <additional_attributes>10.0;10.0;10.0;50.0</additional_attributes>
   </element>
   <element>
     <id>Text</id>
     <coordinates>
-      <x>420</x>
-      <y>180</y>
-      <w>100</w>
-      <h>70</h>
+      <x>276</x>
+      <y>24</y>
+      <w>120</w>
+      <h>84</h>
     </coordinates>
     <panel_attributes>T is a type parameter
 style=wordwrap</panel_attributes>
@@ -56,10 +56,10 @@ style=wordwrap</panel_attributes>
   <element>
     <id>UMLClass</id>
     <coordinates>
-      <x>530</x>
-      <y>180</y>
-      <w>190</w>
-      <h>90</h>
+      <x>408</x>
+      <y>24</y>
+      <w>228</w>
+      <h>108</h>
     </coordinates>
     <panel_attributes>&lt;&lt;interface&gt;&gt;
 Iterator[T]
@@ -70,21 +70,21 @@ __next__(): T</panel_attributes>
   <element>
     <id>Relation</id>
     <coordinates>
-      <x>620</x>
-      <y>260</y>
-      <w>30</w>
-      <h>70</h>
+      <x>516</x>
+      <y>120</y>
+      <w>36</w>
+      <h>84</h>
     </coordinates>
     <panel_attributes>lt=&lt;&lt;.</panel_attributes>
     <additional_attributes>10.0;10.0;10.0;50.0</additional_attributes>
   </element>
   <element>
     <id>UMLClass</id>
     <coordinates>
-      <x>530</x>
-      <y>310</y>
-      <w>190</w>
-      <h>70</h>
+      <x>408</x>
+      <y>180</y>
+      <w>228</w>
+      <h>84</h>
     </coordinates>
     <panel_attributes>ConcreteIterator
 --

patterns/index.md

@@ -2,68 +2,85 @@
 title: Design Patterns
 ---
 
-*Design Patterns* are reusable designs for common situations. 
+Presentation: [Intro to Design Patterns](Intro-Design-Patterns.pdf)
+
+*Design Patterns* are reusable designs for common, recurring situations. 
 
 Each design pattern consists of:
 
 * **Context** - a situation where a design solution is needed
 * **Forces** (or Motivation) - motivation or "needs" of the situation
 * **Solution** - a design that solves the problem
-* **Applicability** - when the pattern applies.  There may be many solutions to a particular context; the applicability can help.
+* **Applicability** - when the pattern applies.  The "applicability" can help you choose between multiple possible solutions and avoid misusing a pattern.
 * **Consequences** - good and back effects of this solution
-* **Example** - at least one example of using the pattern
-
-Presentation: [Intro to Design Patterns](Intro-Design-Patterns.pdf)
+* **Example** - an example of using the pattern
 
 ### Principles & Goals Motivate Patterns
 
 Design Patterns are motivated by design **Goals** and **Principles**.
 
-Software is plagued by these problems:
+
+The Need: Software is plagued by these problems
 
 * change - requirements change, technology changes, the environment where software is used changes
 * bugs (errors)
 * complexity
-* difficulty to maintain or evolve over time
+* difficult to maintain and evolve over time
 
 These forces have given rise to **principles** for good design and coding.
 
 ## Principles and Goals for Software Design
 
-Some principles for good design have emerged 
-from experience solving the common problems with software,
+These "principles" for good design have emerged 
+from experience solving common problems with software,
 through repeated application.
 
-The design principles are what motivate the design patterns.
+These principles are what motivate the design patterns.
 
-This is only a brief summary and not a complete list.    
+This is only a brief summary.
 Please read the references to learn in more depth.
 
 * **Single Responsibility** - a class should have one responsibility. Robert Martin explains this as *a class has only one reason to change*, e.g. one driver or boss that decides what it should do.
+
 * **Open-Closed Principle** - you can extend the functionality of a class without modifying the class itself
+
 * **Liskov Substtitution Principle** - in an application, you should be able to use a subclass object anywhere it's superclass is expected and the application will behave as expected. Subclasses should pass the "*is a*" test.
+
 * **Don't Repeat Yourself** - avoid duplicate logic and duplicate code (applies to design *and* coding)
+
 * **Prefer delegation over inheritance**. It is more flexible to design objects so that A delegates behavior to B, and set B as an attribute of A, rather than make B a subclass of A that specializes some behavior. The Adapter, State, and Strategy patterns all use delegation.
+
 * **Code to a specification, not an implementation**.  Write code based on the specification (or public interface) for how an object or method *should* behave rather than details of how it's implemented. In Java, depend on the *List* API rather than *ArrayList* (an implementation). 
 * **Depend on abstractions, not on concretions**. Similar to the previous principle, but at a higher (more abstract) level.
+
 * **Don't Reinvent the Wheel**.  Don't write code for something that the language already provides, or something that can be provided by an existing, well-tested and maintained package.  For example, don't write your own CSV file parser or password encrypter. There are lots of these and they contain fewer (if any) flaws that what you would write yourself.
+
 * **Separate what Varies from what Stays the Same, and Encapsulate the part that Varies**.  "What" means "a part of the code or some behavior of the code". 
+
 * **Information Expert** - put a method in the class that has most of the information needed to perform the method.
+
 * **Separation of Concerns** - classes and components (groups of classes) should each be concerned with a single aspect of the program. A Data Access Object is concerned with saving and retrieving objects to/from a database, but doesn't manipulate the objects itself. Separating object creation from object use is often helpful -- e.g. use a Factory for objects.
+
 * **Dependency Injection** - If an object depends on some other object, try to *inject* that dependency from other code, esp if the dependent part may change.  This helps with *Separation of Concerns*, *Separate what changes from what stays the same*, and reduces coupling.
   - Example: in Coin Purse we *inject* a WithdrawStrategy using a `set` method.
-* **Low Coupling**, esp. coupling to unstable or unrelated things. Coupling to the Java API (for Java apps) isn't a problem because the Java API is quite stable.
+
+* **Strive for Loosely Coupled Objects** (Low Coupling), especially. coupling to unstable or unrelated things. Coupling to essential, stable APIs (the Java or Python API, the JDBC API) isn't a problem because these are quite stable and well maintained.
+
 * **Command-Query Separation** - queries should not change the state of an object
+
 * **Simplicity** - complexity is the enemy of correctness and security. Strive for simple designs.
 
 
-Some **goals** for class design (the 5 "C"s of class interface design):
 
-* High Cohension
-* Consistency - be consistent in naming of methods, variables, and classes. Be consistent in their behavior, too.
-* Completeness - a class should provide enough methods for it's intended use.
-* Convenience - try to provide an API that's *convenient* for the programmer, but don't create lots of redundant methods.
-* Clarity - a method or class's name and interface should clearly suggest it's purpose
+## Goals for Class Design
+
+Some **goals** for class design (the 5 "C"s of class interface design)
+
+- High Cohension
+- Consistency - be consistent in naming of methods, variables, and classes. Be consistent in their behavior, too.
+- Completeness - a class should provide enough methods for it's intended use.
+- Convenience - try to provide an API that's *convenient* for the programmer, but don't create lots of redundant methods.
+- Clarity - a method or class's name and interface should clearly suggest it's purpose
 
 
 ## Specific Design Patterns 
@@ -90,14 +107,12 @@ The links are presentation slides.
 ## Learn More
 
 
-Online: 
+* [Refactoring Guru](https://refactoring.guru/design-patterns) has a [catalog of patterns](https://refactoring.guru/design-patterns/catalog) with very visual examples and pseudocode, 
 
 * [Python Patterns Guide](https://python-patterns.guide/) explains how and "why" to apply patterns in Python. Some good insight but I think you need to know a particular pattern before reading his explanation.
 
 * [Wikipedia](https://en.wikipedia.org/wiki/Software_design_pattern) has a list of patterns with a page describing each one,
 
-* [Refactoring Guru](https://refactoring.guru/design-patterns) has a [catalog of patterns](https://refactoring.guru/design-patterns/catalog) with very visual examples and pseudocode, 
-
 * [Geekforgeeks](https://www.geeksforgeeks.org/software-design-patterns/) has good descriptions with UML and Java examples.
 
 * [Game Programming Patterns](https://gameprogrammingpatterns.com/contents.html) application of patterns to games. Examples use C++.