Birth of a developer

18
BIRTH OF A DEVELOPER…….

Transcript of Birth of a developer

Page 1: Birth of a developer

BIRTH OF A DEVELOPER…….

Page 2: Birth of a developer

ATTRIBUTES OF A DEVELOPER.

• Positive Attitude.• Hunger for KNOWLEDGE.• Curiosity.• GREAT team player.• Keeps focus on the BIG PICTURE.

Page 3: Birth of a developer

SOLID PRINCIPLES…

Page 4: Birth of a developer

SINGLE RESPONSIBILITY PRINCIPLE

Page 5: Birth of a developer

• Keep each class to have a single responsibility• More than a single responsibility creates more

coupling• Disregarding the SRP can result in Rigidity and

Fragility

SRP – “A class should have only one reason to change”.

Page 6: Birth of a developer

OPEN CLOSED PRINCIPLE

Page 7: Birth of a developer

• Open for extension means that we change what the module does by extension.  

• Closed for modification means that extending the module ensures that we don’t change the base class so that and other classes extended from it don’t need to change or be recompiled, relinked, etc.

• Achieved through abstraction• Ignoring the OCP results in Rigidity and Fragility.

OCP – “Software entities should be open for extension, but closed for modification.”

Page 8: Birth of a developer

LISKOV SUBSTITUTION PRINCIPLE

Page 9: Birth of a developer

LSP – Let q(x) be a property provable about object x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T

Page 10: Birth of a developer

“SUBTYPES MUST BE SUBSTITUTABLE FOR THEIR BASE TYPES.”

• The Child class should replace the parent class and the functionality should not break.  

• Violating the LSP leads to Fragility.• A violation of LSP is a latent violation of OCP.

Page 11: Birth of a developer

INTERFACE SEGREGATION PRINCIPLE

Page 12: Birth of a developer

• When a client depends on a class that contains methods the client uses, but that other clients do not use, then that client will be affected by all changes that those other clients force upon the class.

• Break the dependence of clients on methods they don’t invoke.

• This allows clients to be independent of each other.

ISP – “Clients should not be forced to depend on methods that they do not use”.

Page 13: Birth of a developer

DEPENDENCY INVERSION PRINCIPLE

Page 14: Birth of a developer

DIP –

1. “High-level modules should not depend on l0w-level modules. Both should depend on abstractions”.

2. “Abstractions should not depend on details. Details should depend on abstractions”.

Page 15: Birth of a developer

TDD… (TEST DRIVEN DEVELOPMENT) DESIGN

Page 16: Birth of a developer

Test-driven development (TDD) is an evolutionary approach to development which combines test-first development (where we write a test before we write just enough code to fulfill that test) and refactoring.So,

 TDD = TFD + Refactoring

Page 17: Birth of a developer
Page 18: Birth of a developer

With great knowledge comes the responsibility of sharing it.