Use interfaces as much as

possible

Procedural programing languages there

are no objects but just procedures
doing something with Data

Data was like a

puppet
procedures were the
playing
lifeless puppets to make them do stuff
puppets themselved cannot
do behaviour
anything
No
just
types
Oops
Data are no more
lifeless
cannot do
puppets who anything
themselves But
by they are
entities who has there own
behaviour
they can do stuff
for themselves
There are still objects that
data do
just
themselves
carry nothing by
but acts as puppets others use
them to do stuff These objects are

called Anaemia objects

when are objects Possible
analmie
when the actual purpose of an

is not known services doing

entity
different stuff on the similar
entity
to procedural programing languages
purpose of an entity means
what is the of the entity in
responsibility
the domain
larger
When the purpose of the entity is
not known property that
mean the
may
domain subdomains are not defined
so entities are convoluted
properly
 9h Oops classes objects are in
control
of these data while non oops
data is Vulnerable
languages
can be controlled others
by
Os arewritten in non oops langua
ges because oops have some
inefficiencies in terms of object
creation etc Os needs
storing
to be efficient cannot afford
even small inefficiencies like
object creation storage etc
where endemic objects used
There be cases where we
may behaviours
not know what
may
the object should have but it
be an whose
data
just
may is used or entity
needed for
different purpose in such cases
we expose Implementation
details properties of the object
let that
purpose use the
details in whichever
way they
 ay hey
In
Want such cases Anemic obj
are used
Example
person name age Qualif
is a simple person now
he she can be used as

a bus driver or a computer

operator so person name

can be composed on
different contextual objects
id
or the same
object
can be created as different
objects based on the purpose
all objects will have same
name with
properties age
additional properties
 Pillars of 00ps PIE

Polymorphism
inheritance
Encapsulation
Il supports
Principle Abstraction

Abstraction
Representing complex system as
a

a set of
high lend ideas without
giving too many lower level
details of the system

Encapsulation
the properties
Hiding
behaviour from outside world
i

making properties behaviour

accessible based on their access specifiers
like private protected default
public etc
 classes are used to implement
encapsulation by binding
properties behaviour together

preventing illegitimate access

to data behaviour
Polymorphism
Method overloading doesn't consider the
return types
only consider signature
So if 2 methods have different
types but
meteen these signature are
same then compiler considers
essentially
them as same method throws
error
compilation
Example
class A

1 Not
overloading float mi Cinta into
ist mi Cinta int b

main C
A a new AC
1 How will Runtime a m 10,20
know which is called
or int mi
float mi
How is evaluated at
assignment
Runtime
int se Add 10 20
Eg
Note For Asignment or
association is
from right to left
so runtime will calculate right
hand side
first then cast the
result with the variable on
type
left

doesn't consider return

Overloading
above
type as
explained
does consider return
Overriding the oneeriden method
type
should have exact same
signature
return
type why
Other it violates the
substitution principle of child
object where parent objects are

Used it creates surprises

method Erasure
signature only
erasure method parameter their

types
is fine until child impt
Overriding
doesn't have element of
any
surprise
Inheritance Is A
relationship
Composition Support composition once
Inheritance Inheritance
creates
unnecessary couplings
 SOLID
Design Principles
a Bird
Example Design
Class Bird
color
weight
type
weight
I Naive 1st Approach
fly
or

of type Crow
I do crow
else if type hen
hen
1 50 on
flya

11 keep on as
adding
new Birds
get added
Observe the that
requirement
varies most gets affected by
Isolate that
different actors
into a
different class
Cyclomatic complexity high means
method doing too
many things
Multiple people working on same
code incurs
merge conflicts
This is violation of SRP
SRP

Any component package class

method should have one
reason to should be
change
responsible for a
single purpose
Reason to be
change may
actorsclients
different
respo sible
for different use cases

the the
governs change of
module package class method

Identify SRP
Method have
many
if else conditional Blocks
class has too many
attributes
Violation Example
utie
packages
Coincidental cohesion
 SRP
why Increase because
it asks to
reusability
create code
smaller
code
from larger
increases
readability by making
it smaller towards
a
working
single purpose
work
Many people can parallaly
with fewer because
merge conflict
it
change for a single
season

always takes
Almost case of

open dose principle

Don't overdo SRP common closure
is better to be followed
for larger
code bodies like package class etc
Think about cohesion
to
along
with SRP create good
clean code
the
Identify context for
coati all
component components
based on there context
Open close Principle Ocp

open for extension closed

for modification
extensible Ease to add new

feature
on
Modify making changes
existing codebase

Add new code as a

function class
or but don't
package change
existing one
based on context or reason
Again the
to
change of existing
Context demands a change then
its ok to modify code
existing
written
already for
same
purpose
IF new context
is
an
needed
entirely it should not
need to change existing code
 Bird class
Solving
SRP OCP
for
Create an Abstract class bird
Implement different type of Birds

extending Bird class implement

C method each Bird
fly subclasses on

Problem what if a Bird subclass

doesn't
flyincorrect options
options
Add a
default flye
on Bird parent class
Of child doesn't implement
any
that child can
fly c have unexpected
fly c behaviour
Of there wasn't a default
implementation then compiler would
have checked enforced child
classes implementing flyer or

would have thrown exception

Issue is unexpected
Runtime behaviour violates
No surprise principle
 child e
Throw exception from fly
Runtime exception can
implementation
be thrown

This result in
may
runtime behaviour
unexpected
which the client
of the
method not have expected
fye
may
Good code bases should
surprise as much as
reduce
possible Principle of least
surprise
Implement blank fly C method in
child
Doing nothing when its
expected to fly is kind of a
surprise
Errors should be as
caught
much as
possible compile time
at
So there would be least surprise
at Runtime Fail Fast
Leskov substitution Principle Lsp

child class
object can be
used where
anywhere parent class
is used
child where
using object
used should not
parent is
produce surprise or
unexpec ed
any
behaviour at runtime

Child objects should not

give
any Nosurprise
child should be handled
client
differently by
How to handle case where Bird can't

Fly
Create subclasses to handle
each case where birds can
can't eat can't eat
fly or
decoo
fly
Bird

L T
flyingBird NonflyingBird
L

NOEInonp .ir
Eaterybird Spiffy Ebony
É
If there are N attributes will have
2N such Classes that a class
explosion which is Bad

Create with each

Interfaces type
flyable Interface
Eatable Interface
Walkable interface
etc
 we each
to
segregate functionality
respective Interfaces
implement them as needed
This is called Isp interface
segregation Principled

Interface segregation Principle lsp

A class should have

only
those methods which are Obvious
behaviour of the class
All cilds will
always
inherit those obvious behaviours

Ise inheritance for handling

entities not behaviour

Dont use inheritance to handle

behaviour difference use Interface
The child class can have same
behavioural trait method as
but child implement
parent always
it then thats handled
differently through
overrides no need separate
for
interface for this case
behavioral difference it
mean
Bychild classes or not
inherit the behaviour
may may at
of parents
all in which cases poll that
behaviour out of parent handle it
through interfaces

Ok so we moved eat methods

to eatable let
fly
interfaces
flyable classes
the respective child implement
them as these requirement
per
what if a client needs both
flyable
eatable birds
Check if there is SRP
Violation on the client because
a client should need
generally
only one
type if designed
properly
 Of 1 is not case then create
an interface eaterflier which extends
eatable interfaces
friable

If should be as
interfaces
lean says then as I
possible
should not be thick

inversion D1
Dependency
on
Always depend
interface not on concrete Implementation

Questions to ask
what is the context of the

system
Ask points that if changed
will affect the
design
what is start or termination

strategy for system