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