Software Design & Architecture on my mind

@werockstar Kotchaphan Muangsan, 10/10/2020 Software Design/Architecture on my mind Care
about your craft, Think about your work

@werockstar @werockstar Kotchaphan Muangsan Software Developer @ODDS

@werockstar แนะนำตัวและคาดหวังอะไรจากคลาสนี้

@werockstar

@werockstar Feel free to ask any question (while I talking)

@werockstar Foundation of OO Design

@werockstar https://github.com/WeRockStar/ Software-Design

@werockstar Just guidelines

@werockstar Everything in software architecture is a trade-off Fundamentals of
Software Architecture, Neal Ford and Mark Richards

What I want to share to you all? - What
is design/architecture? - Classical/Essential OOP? - Coupling and Cohesion - Many Principles - Testing - Design Pattern - Legacy Code - Code Smell - What are missing? @werockstar

@werockstar Anonymous Don’t believe me and I also don’t believe
myself

@werockstar What is architecture? https://unsplash.com/photos/VviFtDJakYk

@werockstar https://unsplash.com/photos/-HIiNFXcbtQ

@werockstar Architecture • Module, connections, dependencies and interface • The
big picture • Design with bigger picture in mind • Interface rather than implementation • A conceptual model • A plan • A blueprint • System, Subsystem, interactions and interfaces • Mindset • The system as a whole • Everything, Everything, and Everything Source: Software Architecture for Developers Vol.1

@werockstar The structure of a software product. This includes elements,
the externally visibility properties of the elements, and the relationships between the elements Bass et al. 2012

@werockstar The software architecture of a system is the set
of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. Software Architecture in Practice, 3rd Edition

@werockstar Software Architecture = the sum of all important decisions
Kruchten 2004

@werockstar Structure, Vision, Decision

@werockstar Fundamentals of Software Architecture

@werockstar What is design? https://unsplash.com/photos/ZSPBhokqDMc

@werockstar https://unsplash.com/photos/OjwQ9WywGsw

@werockstar https://unsplash.com/photos/534UrITBKYM SOLID FP OOP FRP Patterns DDD More Code
Arrangement

@werockstar Which one?

@werockstar Uncle Bob, Author of Clean Architecture, Clean Code, etc.
The low-level details and the high-level structure are all part of the same whole. You can’t have one without the other

@werockstar Uncle Bob, Author of Clean Architecture, Clean Code, etc.
The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity.

@werockstar https://unsplash.com/photos/vYyTAjJuuL4

@werockstar Paradigms

@werockstar Paradigms Ways of programming, relatively unrelated to language

@werockstar OOP - Object-oriented Programming

@werockstar ถ้าพูดถึง OOP เรานึกถึงอะไร?

@werockstar การเขียนโปรแกรมเชิงวัตถุ

@werockstar I think, I don’t know about an OOP at
all https://unsplash.com/photos/vYyTAjJuuL4

@werockstar Object, Class, Abstract class, Interface, Inheritance, Encapsulation, Polymorphism, Abstraction,
Composition, Superclass, Subclass

@werockstar What is the big idea?

@werockstar Object?

@werockstar Inheritance?

@werockstar The combination of data and function?

@werockstar A way to model the real world?

@werockstar That’s good

@werockstar What actually happens?

@werockstar Clean Architecture book, Page 22 Object-oriented programming impose discipline
indirect transfer of control

@werockstar Alan Kay OOP to me means only messaging, local
retention and protection and hiding of state- process, and extreme late-binding of all things

@werockstar Alan Kay I’m sorry that I long ago coined
the term ‘object’ for this topic because it gets many people to focus on the lesser idea. The big idea is messaging

@werockstar Message Passing • Communication mechanism between objects by passing
message • Decoupling objects from each other • Message Passing involves name of object, name of method(message) and information to be send • Care about contract, don’t care about implementation https://unsplash.com/photos/fN603qcEA7g

@werockstar Message Passing class Messaging(private val robot: Robot) { fun
send() { robot.walk(10) } }

@werockstar Local retention, … and hiding of state-process • Locally
within objects • Encapsulating state • State changes are controlled at a local • Not command • No direct referencing of internal state https://unsplash.com/photos/DRzYMtae-vA

@werockstar Extreme late-binding • Runtime adaptability • Looked up implementation
at runtime • Dynamic binding • Polymorphism? • Flexibility? https://unsplash.com/photos/P9zwFXDtDfs

@werockstar OOP Today?

@werockstar Joke?

@werockstar Change one break everything

@werockstar How to solve these problem?

@werockstar Coupling, Cohesion, and Connascence

@werockstar Why?

@werockstar Managing dependencies Arrange dependencies Aware impact of change

@werockstar Adaptive Code 2nd Edition, Gary McLean Hall Coupling is
the strength of interdependence between software elements

@werockstar Software Elements • Property/State/Attribute • Method/Function • Class •
Package/Group • Namespace/Module • Solution https://unsplash.com/photos/9cCeS9Sg6nU

@werockstar In another word, Coupling speaks to how changing one
thing requires a change in another

@werockstar แปลเป็นไทยว่า “รู้เรื่องคนอื่นเยอะเกินไป” หรือเรียกง่าย ๆ ว่า “เสือก”

Example: High Coupling Code

Coupling forced by framework (Implicit coupling) UI Interact with UI
Source: Thinking in Compose Diﬀerent Language

Coupling forced by framework (Implicit coupling) Source: Thinking in Compose

Deﬁne in the same language (Explicit coupling) Source: Thinking in
Compose

Deﬁne in the same language (Explicit coupling) Source: Thinking in
Compose High Coupling?

Talking in the same language Source: Thinking in Compose High
Cohesion?

In iOS Development, pretty the same thing Compose and SwiftUI
are safe to say explicit coupling

@werockstar Adaptive Code 2nd Edition, Gary McLean Hall Cohesion is
the strength of contextual relationship between software elements

@werockstar In another word, Cohesion talks to how we related
code The code that changes together, stays together

@werockstar Scope of change the codes

@werockstar แปลเป็นไทยว่า “ไม่ค่อยเกี่ยวกับกู ไม่รู้ก็ได้มั้ง”

Example: Low Cohesion Code

Cohesion in many level

Cohesion in Class

Cohesion in Module (Bigger picture) A valid relationship between classes
occurs when: • Same layer of application architecture • Same bounded context of the application Adaptive Code 2nd Edition, Gary McLean Hall

Same layer of application architecture Classes that relate to the
same layer can live together in the same module, whereas classes that relate to different layers must be separated by at least a module boundary Adaptive Code 2nd Edition, Gary McLean Hall User Interface Data Access Business Logic

Same bounded context of the application Classes that relate to
the same bounded context can live together in the same module, whereas classes that relate to different bounded contexts must be separated by at least a module boundary. Adaptive Code 2nd Edition, Gary McLean Hall

@werockstar Cohesion in Microservices • To guarantee independent deployability, we
need to ensure our services are loosely coupled. • We need to be able to change one service without having to change anythings else. https://unsplash.com/photos/9cCeS9Sg6nU Source: Monolith to Microservices, Sam Newman

I have a question https://unsplash.com/photos/AoqgGAqrLpU

Which one is correct? A B

@werockstar Ask more question to yourself

@werockstar More Example

Cohesion in Bangkok

Cohesion in Bangkok Message Passing

I have a question https://unsplash.com/photos/AoqgGAqrLpU

@werockstar What else about of coupling?

@werockstar Dynamic Static Connascence

@werockstar Larry Constantine Attempting to divide a cohesion module would
only result increased coupling and decreased readability

@werockstar Actually, That’s all about my class

@werockstar Good time to celebrate

@werockstar And also, good time to talking about boring topics

@werockstar SOLID Design Principle

@werockstar SOLID • SRP - Single Responsibility • OCP -
Open-closed • LSP - Liskov substitution • ISP - Interface segregation • DIP - Dependency Inversion https://unsplash.com/photos/9cCeS9Sg6nU

@werockstar Clean Architecture book, Uncle Bob Historically, A module should
have one, and only one, reason to change Single Responsibility Principle

@werockstar Is is too simple?

@werockstar Class should do one, and only one thing

@werockstar Really?

@werockstar It is not the SRP

@werockstar Responsibility mean “Reason to Change” or One reason to
change Single Responsibility Principle

@werockstar A module should be responsible to one, and only
one, actor Again, Single Responsibility Principle

@werockstar Software system changed to satisfy users and stakeholders; those
users and stakeholders are the “reason to change” that the principle is talking about Responsible to one actor (User point of view)

@werockstar - Only one concept - One ubiquitous language -
Closely related High cohesion?

@werockstar Developers have a tendency to attempt to solve specific
problems with general solutions This leads to coupling and complexity at first - Greg Young

@werockstar Following the SRP each concrete class is very specific
Being Concrete Early and Often

@werockstar Example: ODDS worklogs Employee - Role - You -
Calculate salary - P’Roof - 50 ทวิ & Report & สำเนาบัตร - Accounting

@werockstar Simple example: Bank Account

@werockstar Agile Principles, Patterns, and Patterns in C#, Uncle Bob
Software entities (class, module, function, etc.) should be open for extension but closed for modification Open-closed Principle

@werockstar Bug fixing? That’s ok!

@werockstar The are open for extension The are closed for
modification

@werockstar If OCP is applied well, further changes of that
kind are achieved by adding new, not by changing old that already works

@werockstar Is it too hard?

@werockstar No, it isn’t. Because we have a Shape, Circle,
and Rectangle haha!

@werockstar Animal, Dog, Cat class

@werockstar How?

@werockstar Abstraction?

@werockstar Inheritance?

@werockstar Favor Composition over Inheritance?

@werockstar Example Code: Composite validation

@werockstar Example Code: HoFs validation

Subtypes must be substitutable for their base types Liskov Substitution Principle

@werockstar Real World Software Development, Raoul-Gabriel Urma and Richard Warburton
In other words, extend a class or implement an interface should maintain the behavior they inherit from their parents Liskov Substitution Principle

@werockstar Substitution Principle

@werockstar Rules? • Preconditions can’t be strengthened in subtype •
Postconditions can’t be weakened in a subtype • Invariant of supertype must be preserved in a subtype • Shouldn’t allow state change that your super type disallowed https://unsplash.com/photos/pwpVGQ-A5qI

@werockstar Example Code: SmartCollection

@werockstar

@werockstar Example Code: LotteryChecker

Clients should not be forced to depend on methods they do not use Interface Segregation Principle

@werockstar Client: I will tell you about what I need
to depend

@werockstar - Write interfaces with the client code’s requirements as
a primary concern. - Create smaller interfaces with more directed purposes. - Identify scenarios where interface segregation can be used.

@werockstar Bird Interface

@werockstar Inherited, expect all got one

@werockstar How about good ways?

@werockstar Commonality and Variability Analysis (CVA)

@werockstar How to design interface?

@werockstar What is Commonality? Identify the concepts that the present
in the problem domain

@werockstar We well know about many kind of sort algorithms
At high level of design, we can treat all of these equally because of what they have in common: They all sort

@werockstar What is Variability? Identify concrete implementation the present in
the problem domain

@werockstar Variability of sort algorithms At level of design, we
can speciﬁc all of these to be different kind of sorting

@werockstar Commonality (Abstraction) and Variability (Concrete)

@werockstar Summary 1. Identify commonalities ﬁrst 2. Create abstraction from
these 3. Identify derivations with the variations of the commonalities 4. See how the commonalities related to each other Source: Design Patterns Explained, 2nd Edition

@werockstar Role Interface

@werockstar

@werockstar ArrowShootable

@werockstar Reused Abstraction Principle

@werockstar

@werockstar Rule of Three

@werockstar Mark Seemann Having only one implementation of a given
interface is a code smell Reused Abstraction Principle

@werockstar Dependency Inversion Principle

- High-level modules should not depend on low-level modules. Bot should depend on abstractions. - Abstractions should not depend upon details. Details should depend upon abstractions Dependency Inversion Principle

- High-level modules should not depend on low-level modules. Bot should depend on abstractions. - Abstractions should not depend upon details. Details should depend upon abstractions Dependency Inversion Principle class or object

@werockstar Depends on stable abstraction Invert dependency

@werockstar Program to interface, not an implementation Design Pattern (GoF)

@werockstar I mean, Depends on Abstraction not interface or protocol
(In term of Swift) Invert dependency

@werockstar An interface is just a language construct, not essence

@werockstar Abstraction elimination irrelevant of detail

@werockstar Clean Architecture • Independent of Frameworks • Testable •
Independent of UI • Independent of Database • Independent of any external agency https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

@werockstar Domain Centric

@werockstar Clean Architecture https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html Scream about the domain, not frameworks

@werockstar Scream Architecture Server-side rendering? Microservices? Serverless? gRPC? GraphQL

@werockstar Dependency Rule

@werockstar Dependency Rule https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html Source code dependencies must point only
inward, toward higher-level policy

@werockstar Dependency Rule Nothing in an inner circle can know
anything at all about something in an outer circle The name of something declared in an outer circle must not be mentioned by the code in an inner circle

@werockstar Dependency Rule Frameworks: Yes, I know Domain: No, I
don’t

User Interface Data Access Business Logic

User Interface Data Access Business Logic Essential Detail Detail

@werockstar Essential vs Detail • Space is essential • Usability
is essential • Building material is a detail • Brick is a detail

@werockstar What about details? Web Database Frameworks React Vue Angular
Android iOS PlayStation 5 ยืนเฉย ๆ เขาก็ไม่รัก

@werockstar Pure Language Feature Testable Businesses Logic and No External
Dependency

@werockstar Managing Dependency

@werockstar What is dependency? https://unsplash.com/photos/hokONTrHIAQ

@werockstar Generically, a dependency is a relationship between two distinct
entities whereby one cannot perform some function—or perhaps exist—without the other

@werockstar A B

@werockstar Source: https://www.adnansattar.com/android-architecture-mvc-mvp-and-mvvm-design-patterns-a-detail-tour/

@werockstar is-a and has-a relationship

@werockstar Dependency Injection Helping us loose coupling

@werockstar The Law of Demeter (LoD)

@werockstar Law of Demeter (Friends zone)

@werockstar เก๋ บี้ แชมป์ ท๊อป

@werockstar Example: LoD

@werockstar เก๋ บี้ แชมป์ ท๊อป

@werockstar DIP: Dependency Inversion Principle

@werockstar Testing • Deﬁnition Unit of Work • Good Unit
Test • Test Smell, Good design and Testability • Test Coupling between production code? • Don’t Test me, please. Why? • New Line Pattern • More Speciﬁc • Strict with behaviors, not structure of elements • Test Double • London school and Classical https://unsplash.com/photos/ilSnKT1IMxE

Definition of Unit Test A unit test is a piece
of code that invokes a unit of work and checks one specific end result of that unit of work The Art of Unit Testing, 2nd Edition

Overview - AAA - Arrange, Act, Assert - SUT -
System Under Test, Subject Under Test - Given-When-Then

Good Unit Test - They run fast - They help
us localize problem - Deterministic

Test Smell, Good design and Testability

Design Smell to Test Smell - Diﬃcult Setup - State
leaks across tests - Leak implementation detail - Coupling with Test only - Diﬃcult to replace with Test Double? - Non-deterministic - God Class with God Test

God Class with God Test Account AccountTest - Where is
withdraw? - Failure with many reason

God Class with Small Test Account WithdrawTest DepositTest *Test *Test

As the tests get more specific, the production code get
more generic - DRY - Don’t Repeat Yourself, Good? - Naming

Code Coverage

Code Coverage Sometimes, They are fake news

Code Coverage No coverage metric can take into account code
path in external libraries

Code Coverage Example: TestCoverage

Production Code and Test Code Both are require maintenance

@werockstar Manager Utils Helper Handler Provider / Service Aware of
these Class

@werockstar Everything in software architecture is a trade-off Fundamentals of
Software Architecture, Neal Ford and Mark Richards

@werockstar It must remain concrete enough to be understood while
simultaneously begin abstract enough to allow for change Sandi Metz

@werockstar Q & A @werockstar Thanks, everyone https://github.com/WeRockStar/Software-Design

@werockstar

Software Design & Architecture on my mind

Software Design & Architecture on my mind

More Decks by WeRockStar

Other Decks in Programming

Featured

Transcript