Software Design Principles and Best Practices - Satyajit Dey
•
0 likes•22 views
The document discusses software design principles and best practices, including definitions of technical debt, stakeholders' goals, causes of technical debt, types of technical debt, code smells, common code smells like comments, uncommunicative names, long methods, and design principles like SOLID principles. It provides examples of single responsibility principle, open-closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle. It emphasizes that good code is readable and maintainable by other programmers.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Software Design Principles and Best Practices - Satyajit Dey
Similar to Software Design Principles and Best Practices - Satyajit Dey (20)
More from Cefalo
More from Cefalo (12)
Recently uploaded
Recently uploaded (20)
Software Design Principles and Best Practices - Satyajit Dey
- 1. Software Design Principles and Best Practices Satyajit Dey Technical Lead Cefalo Bangladesh Ltd
- 2. Technical Debt Metaphor coined by Ward Cunningham in a 1992 report. A concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.
- 3. Stakeholders Goals ● Determine product/market fit ● Critical need to ship products early ● Meet customer needs ● Seize emerging opportunities
- 4. Causes of Technical Debt ● Business pressure ● Lack of understanding of the consequences of technical debt ● Failing to combat the strict coherence of components ● Lack of tests ● Lack of documentation ● Lack of interaction between team members ● Long-term simultaneous development in several branches ● Delayed refactoring ● Lack of compliance monitoring ● Incompetence
- 5. Types of Technical Debt 1. Code debt 2. Design & Architecture debt 3. Test debt 4. Documentation debt
- 6. Technical Debt Figure - Technical debt: The vicious cycle
- 7. Code Smells A code smell is a surface indication that usually corresponds to a deeper problem in the system. —Martin Fowler
- 8. Common Code Smells ● Comments ● Uncommunicative Name ● Long method ● Duplicate Code ● Data Clumps ● Primitive Obsession ● Divergent Code ● Shotgun Surgery ● Switch Statements ● Lazy Class And many more…..
- 9. Comments ● Should only be used to clarify "why" not "what". ● Can quickly become verbose and reduce code clarity. Please don’t do that.
- 10. Uncommunicative Name ● Choose names that communicate intent ● Pick the best name for the time, change it later if necessary
- 11. Long Method Signs and Symptoms A method contains too many lines of code. Reason Developers start coding without reading the existing implementation. Treatment ● Extract Method ● Replace Method with Method Object
- 12. Duplicate Code Signs and Symptoms Code fragments look almost identical. Reasons for the Problem ● Multiple programmers doing same thing at the same time ● Novice programmers may not resist themselves to do Copy/Pasta ● Scary authors don’t allow to refactor their code Treatment ● Extract Method ● Pull Up Field ● Form Template Method, Substitute Algorithm
- 13. Data Clumps Signs and Symptoms Sometimes different parts of the code contain identical groups of variables Reasons for the Problem ● Copypasta programming Treatment ● Extract Class ● Introduce Parameter Object
- 14. Primitive Obsession Signs and Symptoms Use of primitives instead of small objects for simple tasks Reasons for the Problem ● “Just a field for storing some data!” the programmer said ● Creating a primitive field is easier Treatment ● Replace Data values with Object
- 15. Divergent Change Signs and Symptoms You find yourself having to change many unrelated methods when you make changes to a class Reasons for the Problem ● Often these divergent modifications are due to poor program structure or "copypasta programming”. Treatment ● Split up the behavior of the class via Extract Class.
- 16. Shotgun Surgery Signs and Symptoms A single change impact many other classes. Reasons for the Problem ● Poor separation of concerns. ● Failure to understand responsibilities(SRP) Treatment ● Move Method ● Move Field ● Inline Class.
- 17. Switch Statements Signs and Symptoms You have a complex switch operator or sequence of if statements. Reasons for the Problem ● Switch Statements can be scattered in several places ● Need to find all SS for adding new case. Treatment ● Think about Polymorphism
- 18. Lazy Class Signs and Symptoms If a class doesn’t do enough to earn your attention, it should be deleted. Reasons for the Problem ● After refactoring the Class has become less important ● May be designed for future needs! Treatment ● Inline Class ● Collapse Hierarchy.
- 19. Design Principle A set of guidelines that helps us to avoid having a bad design. According to Robert Martin 3 important characteristics of a bad design should be avoided: ● Rigidity ● Fragility ● Immobility
- 20. Two Minutes on Coupling
- 21. SOLID S - Single Responsibility Principle O - Open-closed Principle L - Liskov Substitution Principle I - Interface Segregation Principle D - Dependency Inversion Principle
- 22. Single Responsibility Principle(SRP) A class should have one, and only one, reason to change. ● One class should only serve one purpose ● All the methods and properties should all work towards the same goal ● When a class serves multiple purposes or responsibility then it should be made into a new class
- 23. Open-Closed Principle(OCP) Entities should be open for extension, but closed for modification. ● Add new functionality without changing the existing code ● Use abstraction over implementation ● Helps us to build loosely coupled system
- 24. Liskov Substitution Principle(LSP) Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T. Every subclass/derived class should be substitutable for their base/parent class.
- 25. Interface Segregation Principle(ISP) A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use.
- 26. Dependency Inversion Principle(DI) Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions
- 27. Dependency Inversion Principle(DI) Fig: Procedural System Fig: Object Oriented System
- 28. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” ― Martin Fowler
- 30. Thank You
Editor's Notes
- Sometimes stakeholders set unrealistic deadline of a project.
- We treat everything in the trash as another trash, no matters it is valuable or less valuable
- Generally, any method longer than ten lines should make you start asking questions. The majority of a programmer’s time is spent reading code rather than writing code It is usually a sign that the method has too many responsibilities Long methods make code hard to maintain and debug
- For example: (such as parameters for connecting to a database)
- Primitive obsessions are born in moments of weakness Then another field was needed and added in the same way.
- For example, when adding a new product type you have to change the methods for finding, displaying, and ordering products. Payoff Improves code organization. Reduces code duplication. Simplifies support.
- Shotgun Surgery resembles Divergent Change but is actually the opposite smell. Divergent Change is when many changes are made to a single class. Shotgun Surgery refers to when a single change is made to multiple classes simultaneously
- spreading around logic that should probably be in one place if you add a value to one switch statement you’re likely to need to hunt down all the other ones and change them too. Cyclometic complexity = Number of decisions in the source code
- Rigidity - It is hard to change because every change affects too many other parts of the system. Fragility - When you make a change, unexpected parts of the system break. Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application.
- Primitive obsessions are born in moments of weakness Then another field was needed and added in the same way. It doesn’t mean a class will have only one Method. All the methods should be related to the Goal of the class.
- It’s not only a Principle. We can call it a CONTRACT If a feature/method is specially handled for a given Subclass there is a violation of LSP. For example A getChildren() method of a non-leaf node returns all it’s children but a leaf node might throw exception in this case. Which is clear violation of LSP.
- An example could be AnimalSound interface with bark, mew and moo. In that case Dog, Cat and Cow need to implement relevant methods from that interface.
- Tight coupling between Layers & Sub-layers Any change in the sub-layer will have a ripple effect in the next higher layer and may propagate even further upwards In Object Oriented System both High & Low modules depends on abstraction. So as long is the contract of abstraction is maintained the system will remain flexible.
- May be I can share the what Yves told me at Nandos regarding code refactoring & code quality.