Mubarak
» Skan.ai - chief Architect
» Ai.robotics - chief Architect
» Genpact - solution Architect
» Welldoc - chief Architect
» Microsoft
» Mercedes
» Siemens
» Honeywell Mubarak
Agenda
• Complexity (high -> low)
• Expectations
• Coupling (high -> low)
• Years of Exp
• Cohesion (Low -> High)
• Technology stack
• Composition
• Concurrency design
https://forms.gle/nKn4mG1bVVX1U16x8
Review of code
class is having multiple resp like managing game, game logic. We can have seperate classes
Yes. There should be more classes;
Collecting user input
Run game logic
Store board state
Print board state
have constants
Remove multiple nested if else
cannot be extended if we want to play 4X4
code duplications for checking wining lines and can improve redability
Duplicate code in printBoard
Good
• SRP (***) • Prefer composition over
inheritance
• Low coupling (***)
• Boundary control entity (*)
• Unit testability
• LSP
• YAGNI
• ISP • KISS
• Upcasting/abstraction • Program to an Interface
• DRY • DDD
• • Aggregates
Bad
• Type check • Duplicate code
• Flag check
• Dead code
• dont use overloading on Family of
• Commented code
types
• Downcasting • bool/ null/ int for error handling
• Arrow code • Static methods
• Magic numbers/strings • Singleton GOF pattern
• Tight coupling across units • Functional interface
• Cyclic coupling • God class
• * to * coupling • Avoid Inheritance (extends)
Good (concurrency)
Parallelism
Data Task
Parallelism Parallelism
L1 L1 L1 L2 L1 L3
Dx Dy Dz
Concurrency
CPU Bound IO Bound
If
Supported
Blocking Non Blocking
I/O I/O
80% Custom logic
For concurrency 20% #Thread IO completion
Port
Abstract Thread
Thread Library Library
98% 2%
Data Task Thread
Thread Pool
Parallelism Parallelism
# partition #Thread Short running Long running
# collation
Bad (concurrency)
• Abort
• Suspend
• Sleep
• SetThreadPriority
• Static / shared data
(Global state)
SOC
• Things which do not change together should not be kept
together
• Logic and error handling
• Domain logic and domain rules
• Boundary logic and domain logic
•
Size **
• Fun size • Class size
• Max : fit screen • Max fun : 12
• Avg : < 10 lines • Avg fun: 4
If Flag
Only Data Type changes Only Data changes
Logic remains same Error
Logic remains same Domain
In each path Handling logic
In each Path Rules
Logic changes
== In each Path if(error == true) if(salary > 5000)
Templates/ One class
Interface/ Duck Specification
Generics Multiple Objects Exception Pattern
for each change
Functional
Interface
Function
Object
If Flag
Only Data Type changes Only Data changes
Logic remains same Error
Logic remains same Domain
In each path Handling logic
In each Path Rules
== Logic changes
In each Path
if(error == true) if(salary > 5000)
Templates/ One class Specification
Generics Multiple Objects Exception Pattern
for each change
Functional
Interface
Function
Interface/ Duck
Object
Interface will break
SRP
Delegate to a
Class
[do it outside the family]
10 fun 100 fun
100 lines each 10 lines each
Naming fun ***
Unit test ***
Refactoring ***
With correct abstraction
?
Understand Flow ***
If Flag ==
if(salary > 5000)
Only Data Type changes Only Data changes Error Domain
Logic remains same if(error == true)
Logic remains same Handling logic Rules
Logic changes
Templates/ In each Path
One class Specification
Generics Exception
Object for each change Pattern
Rule Engine
Dual/ Multi Single
Dispatch Dispatch
Interface will break Interface will break
objects from objects from Coupling SRP
Same family different family
Look up Visitor Delegate to a
Visitor / lookup Class
Last weapon [do it outside the family]
Dynamically create Functional
New types Static types Interface
One class
Function
Object for each change Interface/ Duck
Object
If If
{ {
Type changes Value changes
} }
If If
{ {
Type changes Value changes
} }
If If
{ {
Type changes Value changes
} }
1 2 3
Type of Coupling Method call Instantiation Deallocation
Emp obj
Examples of Emp obj
… new Emp()
coupling …
obj.fun();
delete obj;
Abstraction
Approach for # Interface typing * # DI * # smart pointers
Low coupling # Duck typing # factory # virtual destructor
# Lamda
# wrapper
# Garbage collector
Xtreme Approach # reflection # reflection
Architecture
vs
Design
Architecture [Design]
vs
[Code] Design
Quality Approach
• Caching
• Performance
• Indexing
• Security
• Concurrency
• Maintainability
• Pooling
• Reliability
• Data Virtualization
• Availability
• Lazy Loading
• Robustness
• Reusability
• …
• Extensible
1 5
Flag => Interface
# easy to code # low cyclomatic complexity
# readablity
# unit test
# OCP
1
Flag => Polymorphism/
Abstraction/
Interface
Coupling => Polymorphism/
Abstraction/
Interface
Down casting => Polymorphism/
Abstraction/
Interface
Collect Choose
Quality Approach
“system quality”
Domain
Understands
Which : Qualities Collect Choose Approach
How much: Measure << Architecture >>
Knows Architecture design
Blue print
HLD
System Design
Architectural patterns, styles, tactics …
Reference architecture,
Architectural anti patterns,
Technology, domain, …
Code Maintainability
Architecture
Understands
Understand Create
Requirements Code Skeleton
For code (Design)
Knows
Code Design
Technology Low level design
Domain Module Design
proc, OO, fun Class Design
OO Design patterns Implementation Design
Fun Design patterns
Design Principles
Design Anti patterns
Idioms
fun(Bird bird){
Interface Bird{
fly ….
sing
buildNest }
}
Interface LivingThing{ Interface Bird extends LivingThing{
}
Interface Bird extends LivingThing{ }
?
}
fun(Bird bird){
if(….)
bird.fly(); Class Parrot{
…. Interface Bird{
}
}
}
interface LivingThing{
…
}
interface Bird extends LivingThing{
chirp
sound()
}
Interface FlyingBird extends Bird{
fly()
}
Interface NestBuildingBird extends Bird{
makeNest()
}
…
layEggs()
swim()
}
DataHandler
WinHandler MainframeHan
JavaHandler
dler
Win Java Mainframe
DebugHandler DebugHandler DebugHandler
Ref
DebugHandler DataHandler
WinHandler MainframeHan
JavaHandler
dler
a+b 3 cpu cycles
Fun call 10 cpu cycles
Exception handling 1000 cpu cycles
Create thread 200,000 cpu cycles
Write to file 10,00,000 cpu cycles
Db call 40,00,000 cpu cycles
Procedural Prog OO Prog
(tree) (Lego)
P1 classA
Invoice Kst
O CO
Tax
P2 P3 classC
Kst
classB O
Invoice C Tax
O Tax
P4 P5 P6
Cst
classD classE Gst
O
O Tax
Proc OO Functional
Performance n/a n/a ++
Security n/a n/a n/a
Learning Curve ++ -- -
Development Effort ++ -- -
Unit test -- ++ +++
Less Coupling -- ++ ++
Manage large code -- ++ +
Concurrency -- -- ++
Functional Prog OO Prog
(Lego) (Lego)
C F
C F
F
C
F CO
O
C O C
F
C
F O
C C
F O
C
F
O
Interface typing (java, c++, C#) Duck typing (py, js)
Tight coupling
Compiled Languages Dynamic Languages
interface Bird{
void fly();
class Parrot }
{
class Parrot{
void fly(){ class Parrot implements Bird
void fly(){
… {
…
} void fly(){
}
} …
}
}
}
do(Parrot obj) do(Bird obj) do(obj)
{ { {
obj.fly(); obj.fly(); obj.fly();
} } }
do(new Parrot( )) do(new Parrot( )) do(new Parrot( ))
Interface typing (java, c+
Tight coupling Duck typing (py, js) Lamda (py,js, java)
+)
interface Bird{
void f1();
}
class Parrot
{
class Parrot implements class Parrot{ class Parrot{
void fly(){
Bird void f1(){ void fly(){
…
{ … …
}
void f1(){ } }
}
… } }
}
}
do(Parrot obj) do(Bird obj) do(obj) do(Lamda f1)
{ { { {
obj.fly(); obj.f1(); obj.f1(); f1();
} } } }
CA obj = new CA( )
do(new Parrot( )) do(new Parrot( )) do(new Parrot( ))
do(()-> obj.fly() )
Interface typing Duck typing
Tight coupling Lamda (py,js, java) Reflection
(java, c++) (py, js)
interface Bird{
void f1();
}
class Parrot
class CA{
{
class Parrot class Parrot{ class Parrot{ void f1(){
void fly(){
implements Bird void f1(){ void fly(){ …
…
{ … … }
}
void f1(){ } } }
}
… } }
}
}
do(string cn,string fn){
Class c =
do(Parrot obj) do(Bird obj) do(obj) do(Lamda f1)
class.forName(cn);
{ { { {
m = c.getMethod(fn);
obj.fly(); obj.f1(); obj.f1(); f1();
…
} } } }
m.invoke(obj,[]);
}
do(new CA obj = new CA( )
do(new Parrot( )) do(new Parrot( )) do(“Parrot”,”fly”)
Parrot( )) do(()-> obj.fly() )
Store message (“hello”)
API Boundary classes (delegate)
Store message (“hello”)
Control classes
MC MCA MCB
Logic classes
<<entity/domain>>
M A B
Single dispatch Class A
Java, c++, py, ..
Obj1 .fun() Class B
Class C
Dual dispatch
Obj1 & Obj2 .fun()
Multi dispatch
Obj1 & Obj2 & … .fun()
Boundary classes (delegate)
Ui Rest API Message Time Fun Api (dll)
Control classes (orchestration)
Domain/Entity classes
(logic)
Product
Control
… Db Cache Proxy Message Mail
Boundary classes (delegate)
Ui Rest API Message Time Fun Api (dll)
Domain/Entity classes
(logic)
Product
… Db Cache Proxy Message Mail
System
Bounded Context (Inventory) Bounded Context (Accounting)
Boundary classes
Control classes
Workflow classes
Entity classes
Domain classes
Ag1
Ag1 Ag2
Step flow1 start
action1
branch1
action3 action2
stop
DDD
Aggregate
Aggregate
Aggregate
Aggregate
Module
Aggregate
B
A
C Root
DDD
Boundary class
Api (flexible)
Ui
Message
Timer
Domain class
(temple)
Boundary Control Entity
Boundary
Facade
Flow
Domain
Action
• Boundary
• Control
Agg • Entity
Agg
Order Item Root Root
Order Disc Order
… Agg
Root
Code segment Data segment Heap Stack
Util vtbl
0 : CA - 1, CC
1 : CB - 2,
2 : CC - 3 a
void f(CA a) {} //1
void f(CB b) {} //2
void f(CC c) {} //3
Util
vptr U
?
Runtime u.f(a)
u.vptr.vtbl[0](a)
Compile time
Code segment Data segment Heap Stack
CX vtbl[3]
0 : CA - 1,
void f(CA a) {} //1 CC
1 : CB - 2,
void f(CB b) {} //2
void f(CC c) {} //3 2 : CC - 3 a
CY vtbl[3]
void f(CA a) {} //4
void f(CB b) {} //5 0 : CA - 4,
void f(CC c) {} //6 1 : CB - 5,
2 : CC - 6
void f(CA a) {} //7 CZ
void f(CB b) {} //8
void f(CC c) {} //9
CZ vtbl[3] vptr x
0 : CA - 7,
1 : CB - 8, x.f(a)
2 : CC - 9
x.vptr.vtbl[0]
Compile time
Code segment Data segment Heap Stack
SA::Create() SA vtbl[1]
0
CA::Create()
CA vtbl[1]
0 ?
Runtime
CA
vptr account
account.Create()
account.vptr.vtbl[0]
Compile time
UI
Domain
Data Layer
