DESIGN Erik Jõgi [email protected] Why design matters? Longevity. Code is used for years and years. productivity vs time 100 75 50 Productivity 25 0 Time CLEAN CODE Clean Code A Handbook of Agile Software Craftsmanship Robert C. Martin, 2008 “Uncle Bob” “You know you are working on clean code when each routine you read turns out to be pretty much what you expected.” –Ward Cunningham inventor of Wiki and Fit co-inventor of eXtreme Programming FOUR ELEMENTS OF SIMPLE DESIGN 1. Passes all tests 2. No duplication 3. Expresses intent 4. Small Kent Beck — Creator of Extreme Programming, author of JUnit NAMING variables, methods, classes, ... let’s look at some examples… CORRECT ENGLISH ONLY, PLEASE! • Word-for-word translation might not be the correct solution • Use correct domain terminology - ask domain experts what they use • Spelling and grammar • Can you read your code like a story? USE THE SAME TERM CONSISTENTLY • Customer – Client – Party – Counterparty • state – status • Contract – Agreement • get – load – fetch – find – retrieve • regCode – regNumber – personalCode • … and don’t reuse the same term in another meaning/context FUNCTIONS A GOOD FUNCTION • short • very few indentation levels • does only one thing - only one level of abstraction • “Functions should do one thing. They should do it well. They should do it only.” —Robert “Uncle Bob” Martin for example… FUNCTION ARGUMENTS • Less is more! • Ideally none, one and two are OK • Three is usually too much, anything more is a design smell for example… NO SIDE-EFFECTS • A function that seems to be read-only according to its name, should behave as such • If a function changes state then name it accordingly COMMENTS NO COMMENTS! • Comments lie: • You cannot tie them to code • You cannot refactor them • You cannot test them • The truth is in the code • Do not use a comment when an appropriately named variable or function would do! for example… WHEN ARE COMMENTS OK? “The proper use of comments is to compensate for our failure to express ourselves in code.” • Legal comments • Warning of consequences • TODO comments • Amplification • javadocs in public APIs KEEP YOUR CODE CLEAN THE BOY SCOUT RULE Leave the campground cleaner than you found it Can you imagine working on a project where code simply got better as time passed? Do you believe that any other option is professional? OBJECT-ORIENTED DESIGN Agile Software Development Principles, Patterns, and Practices Robert C. Martin, 2003 INTERFACES AND ABSTRACT CLASSES Ignore implementation details Program to interfaces JAVA COLLECTIONS API • Iterable • Collection • List: ArrayList, LinkedList • Set: HashSet, LinkedHashSet • SortedSet: TreeSet • Map: HashMap, LinkedHashMap • SortedMap: TreeMap JAVA.IO • byte based I/O • InputStream & OutputStream • FileInputStream, SocketInputStream, ByteArrayInputStream, GZIPInputStream • character based I/O • Reader & Writer • FileWriter, StringWriter, OutputStreamWriter abstract class example… DEPENDENCY INJECTION INVERSION OF CONTROL • The Hollywood Principle: Don’t call us – we’ll call you • Don’t create your dependencies - they will be given to you • Cleaner design • Easier to test DI example… DEPENDENCY INJECTION • Guice – github.com/google/guice • Dagger - google.github.io/dagger/ • Spring Framework – projects.spring.io/spring-framework/ • Mockito – mockito.org FAVOR COMPOSITION OVER INHERITANCE • Inheritance is for “is-a” relationships - when the same interface is most logical • Composition is for “consists-of”, “contains”, “uses”, “has” relationships - providing decoupling – independence of each other's changes for example… IMMUTABILITY • An immutable object is an object whose state cannot be modified after it is created • What is the most common immutable object in the Java SDK? • Why? Caching, thread-safety, map keys DESIGN PATTERNS Design Patterns Elements of Reusable Object-Oriented Software [Gang of Four Book – GOF] Erich Gamma Richard Helm Ralph Johnson John Vlissides 1994 PATTERNS • Common solutions to frequent problems arising in object-oriented design • A systematized catalog of solutions by skilled and experienced developers • Simplifies communication between developers – “we are using the Strategy pattern” CREATIONAL PATTERNS the process of object creation Factory Method Abstract Factory Builder Prototype Singleton STRUCTURAL PATTERNS the composition of classes Decorator Adapter (Wrapper) Proxy Façade Flyweight Bridge Composite Null Object BEHAVIORAL PATTERNS how classes or objects interact and distribute responsibility Template method Observer (Publish-Subscribe, Listener) Interpreter Memento Chain of Responsibility BEHAVIORAL PATTERNS how classes or objects interact and distribute responsibility State Command Strategy Iterator Visitor Mediator Refactoring to Patterns Joshua Kerievsky, 2004 Avoid: - over-engineering - under-engineering “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” –Antoine de Saint-Exupery FINAL WORLDS The Boy Scout Rule Experience, experience, experience Read a lot of others’ code.