Basic Code Design

Stoyan Stoyanov 

github.com/mrsn

WeltN24 GmbH

Motivation

• inspecting production incidents leads often to reading code which is not good designed
• avoiding technical debts in the future ($)
• you build it, you run it

Goal

• no bashing
• continuous learning/improving
• more fun and time for the important things

Patterns in our codebase

• OOP?
• tight coupling
• no space to move

SOLID Principles

• Single Responsibility
• Open-Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion
• DRY
• Law of Demeter

Single Responsibility

• A class should be responsible for only one thing
  • everything in the class is highly related to its purpose
• enforce this everywhere (functions, services)
• "What does a Mr. Function do?"
  • BAD: computes that AND that AND that AND AND that AND that AND that ...
  • GOOD: no AND

The purpose of software engineering is to control complexity, not to create it.

Pamela Zave

 

Single Responsibility

• Why it matters:
  • code is easy to understand (wow)
  • encourages code reuse
  • code can be tested
  • code can be easily refactored
  • no need of comments
    • please stop writing comments, write functions instead

Open-Closed

• classes, modules and functions
  • should be open for extension
  • should be closed for modifications
  • http://www.oodesign.com/open-close-principle.html

Liskov Substitution

• subtype should be replaceable for the supertype without altering the correctness
• violation of Liskov Principle violates the Open-Closed Principle
• http://www.javacodegeeks.com/2011/11/solid-liskov-substitution-principle.html

Interface Segregation

• many client-specific interfaces are better than one general-purpose interface
• http://www.oodesign.com/interface-segregation-principle.html

Dependency Inversion

• it's all about abstractions and decoupling
• high-level modules should not depend on low-level modules. Both should depend on abstractions.
• Abstractions should not depend on details. Details should depend on abstractions.
• http://www.oodesign.com/dependency-inversion-principle.html

Law of Demeter

• Only talk to your immediate friends
• Don't talk to strangers
• It's a design smell

return xml.getXML().getBooks().getBookArrary(0).getBookHeader().getBookCategory();

More from the kitchen

• Always go for the most simple solution
  • at the third refactoring you have it
• Deep hierarchies are evil
  •   nobody understands them
• Don't reinvent the wheel (know what's there)
  • don't write own monitoring systems or
  • own build tool or
  • own stress testing tool or
  • the new Spring-Framework or
  • own HA-Tools ..

Suggestions

• Adopt design patterns
  • every week one can present a new pattern in his favorite language
• If you think you need more time to implement the feature better, say it and fight for it.
• Java/Js best practices every week
• Open-Source projects

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

John Woods