Updating content about packaging.

Author: William Kennedy

courses/ultimate/language/README.md

@@ -21,8 +21,8 @@ This is a class for any intermediate-level developer who has some experience wit
 [Interfaces](../../../topics/interfaces/README.md) | 
 [Embedding](../../../topics/embedding/README.md)
 
-#### Exporting
-[Exporting](../../../topics/exporting/README.md)
+#### Packaging / Exporting
+[Packaging/Exporting](../../../topics/exporting/README.md)
 
 #### Nature of Types
 [Receiver Choices](../../../topics/receiver_choices/README.md)

topics/arrays/README.md

@@ -5,6 +5,7 @@ Arrays are a special data structure in Go that allow us to allocate contiguous b
 ## Notes
 
 * If you don't understand the data, you don't understand the problem.
+* If you don't understand the cost of solving the problem, you can't reason about the problem.
 * If you don't understand the hardware, you can't reason about the cost of solving the problem.
 
 * Arrays are fixed length data structures that can't change.

topics/exporting/README.md

@@ -1,4 +1,4 @@
-## Exporting
+## Packaging / Exporting
 
 Packages contain the basic unit of compiled code. They define a scope for the indentifiers that are declared within them. Learning how to package our code is vital because exported identifiers become part of the packages API. Stable and useable API's are incredibily important.
 
@@ -27,68 +27,67 @@ _I think that the real problem with C is that it doesn't give you enough mechani
 
 ##  Package Design
 
-**Sandi Metz : Less - The Path to Better Design:**  
-https://vimeo.com/26330100
+#### Mike Action : Data-Oriented Design and C++
+https://www.youtube.com/watch?v=rX0ItVEVjHc
 
 * If you don't understand the data you are working with, you don't understand the problem you are trying to solve.
 
-* Every problem is a data transformation problem at heart and each function, method and workflow must focus on implementing their specific data transformation.
-
-* If your data is changing, your problem is changing.
-
-* When your problem is changing, the data transformations you have implemented need to change.
-
-* You must do your best to guess what data could change over time and consider how these changes will affect the software.
-
-* Uncertainty about the data is not a license to guess but a directive to decouple.
-
-* In many languages folders are used to organize code, in Go folders are used to organize API's (packages).
-
-* Packages in Go provide API boundaries that should focus on solving one specific problem or a highly focused group of problems.
+* If you don't understand the cost of solving the problem, you can't reason about the problem.
 
-* You must understand how changes to the data for a particular package affects the other packages that depend on it.
+* If you don't understand the hardware, you can't reason about the cost of solving the problem.
 
-* Recognizing and minimizing cascading changes across different packages is a way to architect adaptability and stability in your software.
+* Solving problems you don't have, creates more problems you now do.
 
-* When dependencies between packages are weakened and the coupling loosened, cascading changes are minimized and stability is improved.
+* Every problem is a data transformation problem at heart and each function, method and workflow must focus on implementing their specific data transformation.
 
-* Decoupling means reducing the amount of intimate knowledge packages must have about each other to be used together.
+* If your data is changing, your problem is changing.
 
-* Interfaces provide the highest form of decoupling when the concrete types used to implement them can remain opaque.
+* When your problem is changing, the data transformations you have implemented need to change.
 
-**Scott Myers : The Most Important Design Guideline:**  
+#### Scott Myers : The Most Important Design Guideline
 https://www.youtube.com/watch?v=5tg1ONG18H8
 
 * Make Interfaces easy to use correctly and hard to use incorrectly.
 
 * Principle of least astonishment.
-	
 	* Keep the expectation clear, allows users to guess correctly.
-
 	* Take advantage of what people already know.
-
 	* Behavior should maintain a level of expectation.
 
 * Choose good names.
-
 	* Names are the interface.
-
 	* Give a lot of thought to the names you use.
 
 * Be consistent.
 
 * Document before using.
-
 	* Test driven design.
-
 	* This is identify problems early on.
 
 * Try to minimize user mistakes with the API.
-
 	* Trying to constrain values can create readability issues.
-
 	* Minimize choices.
 
+#### Decoupling Guidelines For Go
+
+* In many languages folders are used to organize code, in Go folders are used to organize API's (packages).
+
+* Packages in Go provide API boundaries that should focus on solving one specific problem or a highly focused group of problems.
+
+* You must do your best to guess what data could change over time and consider how these changes will affect the software.
+
+* Uncertainty about the data is not a license to guess but a directive to decouple.
+
+* You must understand how changes to the data for a particular package affects the other packages that depend on it.
+
+* Recognizing and minimizing cascading changes across different packages is a way to architect adaptability and stability in your software.
+
+* When dependencies between packages are weakened and the coupling loosened, cascading changes are minimized and stability is improved.
+
+* Decoupling means reducing the amount of intimate knowledge packages must have about each other to be used together.
+
+* Interfaces provide the highest form of decoupling when the concrete types used to implement them can remain opaque.
+
 ## Code Review
 
 [Declare and access exported identifiers](example1/example1.go)