Birth of a developer
-
Upload
piyush-rahate -
Category
Software
-
view
20 -
download
0
Transcript of Birth of a developer
BIRTH OF A DEVELOPER…….
ATTRIBUTES OF A DEVELOPER.
• Positive Attitude.• Hunger for KNOWLEDGE.• Curiosity.• GREAT team player.• Keeps focus on the BIG PICTURE.
SOLID PRINCIPLES…
SINGLE RESPONSIBILITY PRINCIPLE
• 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”.
OPEN CLOSED PRINCIPLE
• 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.”
LISKOV SUBSTITUTION PRINCIPLE
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
“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.
INTERFACE SEGREGATION PRINCIPLE
• 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”.
DEPENDENCY INVERSION PRINCIPLE
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”.
TDD… (TEST DRIVEN DEVELOPMENT) DESIGN
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
With great knowledge comes the responsibility of sharing it.