Upgrade to Pro — share decks privately, control downloads, hide ads and more …

From Good to SOLID

From Good to SOLID

From the talk at CodeTalks Conference 2018

Working with companies from early-stage startups to Fortune 500, I've experienced both the struggle of continuing someone else's work and the joy of it. The difference is only in their approach towards the design of their code. It's a minor effort if done on time, with a huge impact on the overall development of the software. In this presentation, we'll focus on what distinguishes a good developer from a strong one and learn how to stand out from the crowd.

Katerina Trajchevska

October 19, 2018
Tweet

More Decks by Katerina Trajchevska

Other Decks in Programming

Transcript

  1. Katerina Trajchevska • Senior Software Engineer & co-founder of Adeva

    • Remote Work Advocate • Community Volunteer • Consultant with startups and Fortune 500 companies Software Engineer and co-founder of Adeva
  2. @ktrajchevska SOLID Design Principles • Encourage writing code that is:

    ◦ Easier to read and understand ◦ Easier to maintain ◦ Easier to extend • Introduced by Robert Martin (Uncle Bob), named by Michael Feathers.
  3. @ktrajchevska Single Responsibility Principle • A class should only do

    one thing. • Find one responsibility and move everything else out of the class. • Very precise names for many small classes > generic names for large classes.
  4. @ktrajchevska Open/Closed Principle • Extend functionality by adding new code

    instead of changing existing one. • Easily extend the system; never break it. • Example: Open Source library
  5. Liskov Substitution Principle Let φ(x) be a property provable about

    objects x of type T. Then φ(y) should be true for objects y of type S where S is a subtype of T.
  6. @ktrajchevska Liskov Substitution Principle • Any class should be able

    to substitute its parent class without breaking the program. • Every class that implements an interface, must be able to substitute any other class that implements the same interface without breaking the program. • Every part of the code should get the expected result.
  7. @ktrajchevska Interface Segregation Principle • A client should never be

    forced to depend on methods it doesn't use. • Changing one method in a class shouldn’t affect classes that don’t depend on it. • Replace a large interface with many small, specific interfaces.
  8. @ktrajchevska Dependency Inversion Principle • Never depend on anything concrete,

    only depend on abstractions. • High level modules should not depend directly on low level modules. • Able to change an implementation easily without altering the high level code.
  9. @ktrajchevska ⚠ Words of caution • SOLID design principles are

    principles, not rules. • Know your trade-offs and use common sense when applying SOLID. • Avoid over-fragmenting your code. • Don’t try to achieve SOLID, use SOLID to achieve better developer experience.
  10. @ktrajchevska Final Thoughts • SOLID helps you achieve code that’s

    easy to maintain, extend and understand. • Spend more time writing and less time reading code. • Always know your trade-offs and use common sense.