Building on SOLID foundations - Steve Freeman & Nat Pryce - Breakout Session from Software Architect 2013

gistfile1.txt

https://www.youtube.com/watch?v=6Bia81dI-JE

Building on SOLID foundations - Steve Freeman & Nat Pryce

10:00 - Ravioli Code
12:15 - Spaghetti and Meatballs
          * Brittle event flow tying objects together
13:30 - Tangle of Wires
          * You can wiring your objects together, using DI, but everything
            is just tangled together with all of this wiring between objects
          * "Let's have lots of objects and wire them together" - all objects
            can see each other, "Oh I need this, i'll just pull it out of the
            sky"
          * Loss of localities, all dependencies are smeared across the entire
            system
16:49 - Auto Wiring Containers
          * Opposite of "Tangle of Wires"
17:34 - Helper Class
          * Objects get bigger and bigger
          * "Order" and "Order Helper"
          * Helpers can't be used elsewhere in the system
          * What happens when the "Order Helper" gets too big?
19:00 - Law of Demeter
          * Objects should only talk to objects to which they are closely
            related
          * Violating LoD locks down a dependency chain
20:20 - Dependency Injection
          * "If you need something, pass it in" over "Reach out and grab it"
20:48 - What about Principles that come into play at a larger scale?
          * Conway's Law
          * Postel's Robustness Principle
          * CAP Theorem
          * End-to-End principle: Error handling should be pushed to the edge
            and handled by clients, not distributed at each of the nodes
            in-between.
          * REST
24:20 - What's missing in the middle?
          * Ports and Adapters - Clean domain model in the middle, around that
            you define ports to the outside world, then you write thin adapters
            that bridge from one to the other
          * MVC, PAC, Pipes and Filters and many others
          * Missing fundamental principles that help us use these patterns
26:30 - Story Time: Building system for Financial Modeling
          * Started with lots of immutable objects
          * Found lots of duplication in "scenario catalog" objects, started
            refactoring, created "object graphs"
          * Ended up with tangle of wires, lots of syntactic noise (33:20)
          * Next step was Factory Objects with sensible names
          * Code started not looking much like Java (34:00,) but started being
            more of a one-to-one real world scenario to code
          * Allowed for rapid changes and quick feedback
          * TDD'd to solution, but found lacking need of acceptance testing
37:00 - "Compositionality"
          * You can understand the entire system by seeing how the pieces
            fit together
          * The Meaning of a compound expression is a function of the meaning
            of its parts and the syntactic rule by which they are combined
          * "We can reason about behavior by reasoning about function design"
          * We've seen this before...
          * <word count program using unix shell>
          * Lots of little programs with defined inputs and outputs bound
            together from which you can build a larger component
          * You can take discrete components that are clean of dependencies
            and you can build larger systems out of them (43:25)
45:30 - Primitive Elements
          * If we try to take the "Compositionality" approach, we will end up
            building these primitive elements and then putting them all
            together
46:10 - Composition Operators
          * With primitive elements, we need operations that help combined
            them back together (e.g. unix pipes)
47:00 - Meaning
          * We need to give these syntactic pieces meaning.
          * Meaning only exists inside of some type of context
          * Write tests for each context
48:00 - Syntax
          * What do these things look like
          * What syntactic forms do we end up with such that we can reason
            about the behavior
48:40 - Test Assertion Syntax Example
          * FEST vs Hamcrest (52:20)
55:10 - "Behavior assembled from immutable objects acting on stateful context"
01:00:52 - "Behavior assembled in multiple Domain Specific Languages"
            * Don't look for universal solutions
01:03:30 - Easier to understand, Easier to Change
            * Things are localized
            * Complexity is managed
            * Scope is managed
            * SOLID objects at the bottom, Big Architecture at the top
            * Helps prevent dependencies that sweep across whole code base
01:04:30 - When building a program, we're building a language
            * Always defining new languages to help solve a bigger problem
            * Principles behind language design
            * All programming interviews should include
              "can you write a paragraph?"
            * Reading code vs. Writing code
            * Dedication to good naming

01:09:10 - Q/A Session
            Q: "A lot of what you're talking about seems to lend itself
                to functional languages."
            A: Any language with a mathematical background lends itself
               to this type of thing.

            Q: "Tips or tricks for writing immutable objects in Java or C#?"
              A: "Do you mean put Final statements everywhere?"
              Q: "Yes, <something about patterns>"
            A: I avoid the builder pattern in Java, but use factory functions
               to compose things together.