Design Patterns Thinking and Architecture at Scale · Copyright © Net Objectives. All Rights...

16 November 2017Copyright © Net Objectives. All Rights Reserved.

Design Patterns Thinking and Architecture at Scale

This talk is based on Net Objectives design patterns training and Al Shalloway and Jim Trott’s book Design Patterns Explained. Please contact Al at [email protected] if you are interested in onsite technical training.

© Copyright Net Objectives, Inc. All Rights Reserved© Copyright Net Objectives, Inc. All Rights Reserved 2

Al Shalloway

[email protected]

@AlShalloway

CEO, Founder

Co-founder of Lean-Systems SocietyCo-founder Lean-Kanban University (no longer affiliated)Contributor to SAFe



Lean ManagementProject Management

technicaltechnical

Lean for ExecutivesProduct Portfolio ManagementBusiness Product OwnerProduct Owner

Onsite SPC Leading SAFe®

Agile ArchitectureProduct Manager/PO

Leanban / Kanban / Scrum ATDD / TDD / Design Patterns

ASSESSMENTSCONSULTING

TRAININGCOACHING


"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."— M. Conway

Conway’s Law



Teams work together well, but interfere with other teams• This makes it difficult to work

• Requires multiple branching• Get in each other’s way

during coding and testing• We’ve likely made the high-

level integration issue worse

Corollary to Conway’s LawWhen you change organizational structure your current application architecture will work against your development teams.

Legacy code was written around different organizational structure that is different from what we have now


A pattern is a solution to a recurring problem in a context.

Patterns According to Christopher Alexander

At this final stage, the patterns are no longer important: the patterns have taught you to be receptive to what is real.” (page 549 of 553)

Patterns are a way of thinking about the relationship between these forces.

Design Patterns Explained: A New Perspective on Object-Oriented Design


copyright © 2010 Net Objectives Inc.

Advice from the Gang of Four


topics

Advice From the Gang of Four

• Design to behavior • Design from the outside in• Consistent with BDD’s Given-When-

Then



topics


• Design to behavior• Use the equivalent of Object-

Injection

• “Equivalent” means to have objects do not know the implementations they are referring to.

• Can use factories to get objects.


topics


• Design to behavior• Use the equivalent of Object-

Injection• Encapsulate variation of

behavior

• Use abstraction (strong contracts –interface or an abstract class)

• Separation of concerns – separate use from construction – want abstractions to be independent

• We are encapsulating over time• Having several algorithms at once, or

one that changes over time is still a strategy.


11 16 November 2017

Abstraction


Consider These

Mop Broom Sponge

Who thinks they are the same?Who thinks they are different?

No Abstaining!



As specific objects: they are differentAs a concept: they are all Cleaning UtensilsWhere/When would we find such a concept useful?

As Any Good Consultant Will Tell You: “It Depends!”


Where does “Cleaning Utensil” exist?

Not in the real world, but in our thoughts as an abstract classification“Cleaning Utensil” does not exist, but is useful nonethelessSometimes, it is actually more useful



Conceptual PerspectiveSpecification PerspectiveImplementation Perspective

Three Levels of Perspective*

* From Martin Fowler’s UML Distilled


Implementation:• Data packaged with function

Specification:• Contract for behavior

Conceptual:• Entities with responsibilities

“Object” Defined



Example of Fowler's Perspectives

ValidationRule+validate(String data):bool

USRule+validate(String data):bool-splitTokens(String data):String[]-validateTokens(String[] tokens):bool

CanadianRule+validate(String data):bool-parse(String data):String-transform(String data):String-applyRule(String data):bool

public boolean validate(String data) {String tokens = splitTokens(data);return validateTokens(tokens);

}

Client

Implementing Classes

Conceptual Class

Specification Relationship

validate(data)


These Can be Extended to Methods

ValidationRule+validate(String data):bool

USRule+validate(String data):bool-splitTokens(String data):String[]-validateTokens(String[] tokens):bool

CanadianRule+validate(String data):bool-parse(String data):String-transform(String data):String-applyRule(String data):bool

public boolean validate(String data) {String tokens = splitTokens(data);return validateTokens(tokens);

}

Client

Specification-level Method

Implementation-level Methods

validate(data)



When designing software, we’d like to be able to consider things in manageable, cohesive, understandable chunks

• We can relate components to each other conceptually

• We implement specific needs within the smaller concept of the component

“Cohesion of Perspective”

"Encapsulate Variation"

"Design to Interfaces"


Commonality-Variability Analysis



James Coplien’s “Multi-paradigm Design for C++”

“Abstraction, in the common English language sense, means to focus on the general and put aside the specific. We abstract by emphasizing what is common and de-emphasizing details. Abstraction is a fundamental analysis tool.”

Commonality-Variability Analysis

His thesis is on line at:http://www.netobjectives.com/files/CoplienThesis.pdf(link is case-sensitive)


“Commonality analysis is the search for common elements that helps us understand how family members are the same” *

Commonalities are• Recognized from experience• Learned through analysis (abstracted)

Commonalities can define basic concepts in a domain

Commonalities

* Multi-Paradigm Design in C++, Jim Coplien



Variability makes sense only in a given commonality frame of reference. It is a variation of some commonality

“From an architectural perspective, commonality analysis gives the architecture its longevity; variability analysis drives its fitness for use”*

Variability Analysis

* Multi-Paradigm Design in C++, Jim Coplien


Motivations and Concepts:Managing Objects Separately from their

Use



Question to Ask

When working on a mature system consider when adding a new function,

which takes longer

writing the new function or

integrating it into the system?


Orthogonal to Fowler's perspectives, we can also make this distinction:• The perspective of Use

vs.• The perspective of Creation

Limiting the perspective of any entity to one of these has advantages as well

Another Similar Distinction



Example Code:

public class SignalProcessor { private ByteFilter myFilter; public SignalProcessor() { myFilter = new HiPassFilter();

} public byte[] process(byte[] signal) { // Do preparatory steps myFilter.filter(signal); // Do other steps return signal;

}}

Java/C#


Mixed Perspectives:

public class SignalProcessor { private ByteFilter myFilter; public SignalProcessor() { myFilter = new HiPassFilter();

} public byte[] process(byte[] signal) { // Do preparatory steps myFilter.filter(signal); // Do other steps return signal;

}}

Use

Creation

Java/C#



We'd like to limit coupling as much as possibleOne way to do this is to:

• Hide the way something is made from • The entities that use it

-and-• Hide the way something is used from• The entity that makes it

What You Hide You Can Change


A New Principle Emerges

The relationship between any entity A and any other entity B in a system should be limited such that

A makes B or A uses B,

and never both.

The relationship between any entity A and any other entity B in a system should be limited such that

A makes B or A uses B,

and never both.

“Separate Use From Creation”



Using an actual factory patternObject Serialization in one place, de-Serialization in anotherObject-Relational Data-BindingDependency Injection FrameworksEtc...

This is a "Principle" -There are Many Ways To Accomplish it


One Ideal Separation (Using a Factory)

SignalProcessor ByteFilterfilter(byte[]):byte[]

HiPassFilterfilter(byte[]):byte[]

LoPassFilterfilter(byte[]):byte[]

ByteFilterFactorymakeByteFilter():ByteFilter

uses

uses

creates

The ByteFilter Polymorphic Serviceuse perspective

creation perspective

This would seem to imply the use of factories to build all objects. Here, it would be overdesign. So what else could we do?



We cannot know when something is going to vary in the futureThis fear can lead to overdesign if we’re not carefulWe need a practice, a fallback to avoid this…

One example: we can encapsulate the constructor* of our classes

All the Benefit Without Excessive Cost

*The original idea for this came from Effective Java by Joshua Bloch


public class ByteFilter { public ByteFilter() {// do any constructor behavior here

}

// the rest of the class follows}

public class SignalProcessor { private ByteFilter myByteFilter; public SignalProcessor() {myByteFilter = new ByteFilter();

}}

Encapsulating the Constructor: Instead of This… Java/C#



public class ByteFilter { private ByteFilter() {// do any constructor behavior here

} public static ByteFilter getInstance() {return new ByteFilter();} // the rest of the class follows

}

public class SignalProcessor { private ByteFilter myByteFilter; public SignalProcessor() {myByteFilter = ByteFilter.getInstance();

}}

Encapsulating the Constructor: Do This… Java/C#

Note that we’ve made a concrete class an abstraction.This is an easy way to introduce abstractions when needed.


public abstract class ByteFilter { public static ByteFilter getInstance(){

switch(Config.FilterType()) { case: Config.HIPASS

return new HiPassFilter();case: Config.LOPASS

return new LoPassFilter();}

} }

public class HiPassFilter : ByteFilter { // Implementation here

}

public class LoPassFilter : ByteFilter {

// Implementation here}

public class SignalProcessor { private ByteFilter myByteFilter; public SignalProcessor() {

myByteFilter = ByteFilter.getInstance(); }

}

Accommodating Change: Complexity

No Change!

C#



Accommodating Change: Complexity

public abstract class ByteFilter { public static ByteFilter getInstance(){

switch(Config.FilterType()) { case: Config.HIPASS

return new HiPassFilter();case: Config.LOPASS

return new LoPassFilter();}

} }

public class HiPassFilter extends ByteFilter { // Implementation here

}

public class LoPassFilter extends ByteFilter {

// Implementation here}

public class SignalProcessor { private ByteFilter myByteFilter; public SignalProcessor() {

myByteFilter = ByteFilter.getInstance(); }

}

No Change!

Java


If the rules for instantiating your objects becomes complex you can move this logic to a factoryThe GetInstance() method can simply delegate to the factory

Once a Factory Becomes Warranted



Encapsulating Construction Allows For1. Easily converting concrete class to abstract class2. Insertion of a factory when warranted3. Enables change in one place

1. Only where object is created2. Doesn’t need to affect multiple clients


Architecture



Related Architectural Principle

If code is aware of the architecture, it should not have application logic.

If code has application logic it should not be aware of the architecture.

If code is aware of the architecture, it should not have application logic.

If code has application logic it should not be aware of the architecture.

“Separate Architecture From Application


topics

Software Development Is Not the Physical World

1. You can’t see the software being developed

• You also can’t see how much is in play or delays in its being built

• Difficult to tell how close it is to completion

• If work on big batches can’t tell if you’re doing the wrong thing or not



topics

Software Development Is not the Physical World


2. Software can be built in increments that can be used

• Can’t use an upstairs bedroom before the downstairs is built

• Can build a piece of software and use it• Can realize value in increments• Can even change foundations• Can use this ability to pivot


topics




3. In software can take advantage of variation

• Don Reinertsen on twitter - IMO at its most profound level AGILE recognizes that it may be smarter to exploit variability than eliminate it -Methodology independent.

• Do something, learn something, pivot



topics




3. You can define the behavior of the software and test it

4. You can encapsulate implementations and later change them

• The cost of encapsulation is low• Often has the side effect of better

thinking (can deal with abstractions, not zillions of special cases).


Offerings Vs CapabilitiesWhen get new offering affects existing capabilitiesArchitecture needs to make this easier

• Add into existing structure• Extend structure (something that had been abstracted now becomes abstracted)

(separation of concerns)• Show practice of separating use from construction

Purpose of architecture



QUESTIONNumber of items to changeHow you find the items to changeDifficulty of making the changeThe safety of making the change

What happens to these forces as scale increases?

What Are The Forces of Change?


Design from big picture.Add distinctions as you go.Abstraction allows us defer decisions on details.Separating use from construction allows us to add the abstractions we discover in looking at the bigger picture• Focus on big picture• Can add abstractions if you missed them• Add details after general layout is done

Chris Alexander Design Via Complexification



How was this designed?


First you have the space

Main



Looked at roads

Main

Roads


Where do houses go?

Main

Houses

Roads



What about ponds?

Main

Houses

Roads

Ponds


Have a park

Main

Houses

Roads

Ponds

Park



Add the trails

Note at this point we are still dealing with concepts.

Architecture specifies how the different concepts relate to each other.

Main

Houses

Roads

Ponds

Trails Park


Now fill in the details

• Roads• Houses• Ponds• Park• Trails

What would you do if you had multiple complexes to build?



Dealing With ChangeOnce and only once conflates two issues:• Where concepts are defined• Where they are used

Another way to think about it: Shalloway’s Law:When N things need to change and N>1, Shalloway will find at most N-1 of the things.

Shalloway’s Principle:Avoid situations where Shalloway’s Law applies


Test Drive Development is the in vogue way to start.TDD is awesome.But in some (especially this) situation, it is RISKY!

Getting from Here to There



Wrap with acceptance tests • Provides safety• Those at a higher level become the general architecture• When have to change existing code

• Refactor code the minimum amount to put in new case properly• This may require adding an abstraction and putting new case under it• May require refactoring to the open closed

• Put totally new things in properly

A Better Approach

© Copyright Net Objectives, Inc. All Rights Reserved 6060

Summary

Attend to Conway’s Law Understand design patterns are about encapsulating

change Understand Architecture is about managing change Patterns are really about how to design and handle

forces Design from context – patterns illustrate intent Take advantage of software being different from the

physical world



Lean ManagementProject Management

technicaltechnical

Lean for ExecutivesProduct Portfolio ManagementBusiness Product OwnerProduct Owner

Onsite SPC Leading SAFe®

Agile ArchitectureProduct Manager/PO

Leanban / Kanban / Scrum ATDD / TDD / Design Patterns

ASSESSMENTSCONSULTING

TRAININGCOACHING

This talk is based on Net Objectives design patterns training and Al Shalloway and Jim Trott’s book Design Patterns Explained. Please contact Al at [email protected] if you are interested in onsite technical training.

Design Patterns Thinking and Architecture at Scale · Copyright © Net Objectives. All Rights...

Documents

Transcript of Design Patterns Thinking and Architecture at Scale · Copyright © Net Objectives. All Rights...