Good system design

Software design is the most important phase of the software development cycle. Thinking about how to structure code before you start writing it is critical. Changes and updates will inevitably arise. Good software design plans and makes allowances for added features, algorithm changes, and new integrations.

By planning ahead, you’ll save valuable time, headache, and cost on maintenance, upkeep, and extension of the original software. Designing software is an exercise in problem-solving. It requires you to break a task down into its component parts, deciding how you’ll address each part and how all the components will assemble together to produce the desired functionality.

As such, the good design relies on a combination of high-level systems thinking and low-level component knowledge. In modern software design, the best practice revolves around creating modular components that you can call and deploy as needed. This creates software that’s reusable, extensible, and easy to test. But before you can create those components, you need to consider what functionality users (or other software) will need out of the software you’re creating.

Transcript

1. Good System Design Ali Rezaiyan
2. Good design? • Cost of change must be minimum • Easy to changes • First try isn’t the best • Refactoring is a usual thing
3. KISS • Complexity makes to change hard • Easy to maintain • Less error prone • Imperative & Declarative Programming Keep It Simple and Stupid
4. YAGNI • Help to keep overthinking • Does we need it now? ◦ Cost? ◦ knowledge? • Test yourself (write a method for sum of two numbers of 2,3) You Aren’t Gonna Need It
5. Cohesion • Narrow • Focus • Do one thing (not taking on several responsibilities) • More cohesive ◦ Less change ◦ Less complexity ◦ More readable ◦ More maintainable ◦ More reusable
6. Coupling • What you depend on! (degree of dependencies) • How to get rid of high coupling! ◦ See dependencies well and remove if it possible ◦ Try to make them loosely coupled
7. enterprisecraftsmanship.com
8. Cohesion and coupling on different levels
9. DRY • Avoid code duplication • The DRY principle states that these small pieces of knowledge may only occur exactly once in your entire system. • Divide a system into parts that are more handy. • DRYness is achieved by good planning. • Pros ◦ Less development cost ◦ Less error prone ◦ More readable Don’t Repeat Yourself
10. SRP • Classes should have a single responsibility and thus only a single reason to change • Write passive • Cons ◦ Reduce reusability ◦ Hard to read ◦ Make low cohesion and high coupling ◦ More cost for maintenance Single Responsibility Principle
11. OCP • Software module should be open for extension but closed from modification • Abstraction • Polymorphism • Cost of change • Before do this think about YAGNI Open Close Principle
12. LSP • Substitution subclass with base class • Don’t throw exception • Don’t change the behavior of base class Liskov Substitution Principle
13. DIP • 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. • Make loose decoupling Dependency Inversion Principle
14. ISP • Make them SRP & high cohesive • Make more decouple • Easy to maintain Interface Segregation Principle
15. Summary • SOLID • DRY • YAGNI • When to Apply these Principles?
16. Good System Design github.com/rezaiyan twitter.com/arezaiyan