Software Design Notes
1 like313 views
This document contains software design notes and principles from Diego Pacheco. Some key points include: - Modules should be designed to be deep with simple interfaces. Classes should also be designed to be deep modules. - Interfaces that resemble implementations indicate shallow design that leaks information and creates poor abstractions. - Comments should describe how to use interfaces, not implementation details, and need to stay close to the code. - Code should be designed to be obvious through use of precise names, patterns, and avoidance of obscurity through event-driven code or generic objects. - Composition should be used over inheritance in object-oriented design. Patterns also risk over-application.
Software Design Notes
- 1. Software Design Notes Diego Pacheco
- 2. @diego_pacheco ❏ Cat's Father ❏ Principal Software Architect ❏ Agile Coach ❏ SOA/Microservices Expert ❏ DevOps Practitioner ❏ Speaker ❏ Author diegopacheco http://diego-pacheco.blogspot.com.br/ About me... https://diegopacheco.github.io/
- 3. Software Design References (for me)
- 4. Software Design References (for me)
- 5. Best Software Design Book in long time(2018)
- 6. Movement vs Anti-Moviment ❏ SOA ❏ Agile ❏ REST ❏ Docker ❏ Clean Code ❏ ...
- 8. Deep Modules and Simple Interfaces
- 9. Notes - Modules are Deep - Classes are modules == Classes are Deep - Deep Modules are better than shallow modules - Classitis when you have too many classes disease - FAT classes hide Information, therefore, creates abstractions - When an interface is similar to implementation means its shallow thus leaking or poor. - Decorator Pattern creates shallow modules - Therefore should be avoided. - Global Context Variable instead of pass-through variables. - Is more important to have a simple interface than a simple implementation - Shallow/lots of private methods are also bad - Exceptions are easy to throw but hard to handle - Better avoid Exceptions as much as possible.
- 10. Notes - Pull Complexity downward not upward(configuration) avoid exposing configs that won't change - Comment what is not obvious - Comments are part of the design - Comment on interfaces should describe just how to use - this should not have comments of the impl. - Comments need to be close to the code otherwise they will get outdated - Long Variable Names VS Short Ones(Go prog Style) - Obscurity is one of the main causes of complexity. - Solution to obscurity is always written code that makes it obvious. - Obvious code means: - Read quickly without much thought - Easily guess meaning or what it does - Guess should be write
- 11. Notes - If the Code is not obvious: - You spend lots of energy to understand. - So its hard to understand and its likely to increase misunderstanding, therefore, creating more bugs - Code Review is the best tool to determine if the code is obvious - Precise and meaningful names make the code more obvious. - 2 Effect that's is important is consistency; Same names == Same Patterns easy to recognize things. - Things that make the code less obvious: - event-driven code - generic objects == containers
- 12. Notes - OOP = Composition over inheritance. - Agile could easily lead to tactical programming. - TDD focus on getting some specific features working rather than have a better design. - Great risk of design patterns - over-application. - More Design Patterns don't mean better design. - Getters / Setters are shallow and should be avoided as much as possible.
- 14. Red Flags
- 15. Closing Thoughts ❏ The Book is amazing. ❏ It's great that the book challenge ideas/assumptions. ❏ I'm not 100% into Comments. ❏ The Book don't cover Functional programing in detail :( ❏ The Book don't cover DevOps Engineering :( ❏ Some sample examples are not practical: Text Editor.
- 16. Software Design Notes Diego Pacheco