What helps a normal coder to become a developer. What are some of the good practices. Vikram singh Shekhawat

1. BIRTH OF A
DEVELOPER…….

2. ATTRIBUTES OF A DEVELOPER.
• Positive Attitude.
• Hunger for KNOWLEDGE.
• Curiosity.
• GREAT team player.
• Keeps focus on the BIG PICTURE.

3. SOLID PRINCIPLES…

4. SINGLE RESPONSIBILITY PRINCIPLE

5. • 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”.

6. OPEN CLOSED PRINCIPLE

7. • 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.”

8. LISKOV SUBSTITUTION PRINCIPLE

9. 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

10. “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.

11. INTERFACE SEGREGATION PRINCIPLE

12. • 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”.

13. DEPENDENCY INVERSION PRINCIPLE

14. 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”.

15. TDD… (TEST DRIVEN
DEVELOPMENT)
DESIGN

16. 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

18. With great knowledge
comes the responsibility of
sharing it.