![What is S.O.L.I.D?
● [S]ingle Responsibility Principle
● [O]pen/Closed Principle
● [L]iskov Substitution Principle
● [I]nterface Segregation Principle
● [D]ependency Inversion Principle](https://image.slidesharecdn.com/basicsoftwareengineeringprincipleswithcodeexamples-session2-211207151227/85/Basic-software-engineering-principles-with-code-examples-Session-2-7-320.jpg)
Basic software engineering principles with code examples - Session 2
- 1. Basic Software Engineering Principles (Session 2) By Lahiru Wijewardana
- 2. What is Software Engineering?
- 3. How Engineer solves a problem ● Understand the requirement ● Plan a solution ● Carry out that plan ● Examine your results for accuracy Solve problems fully BEFORE diving into the implementation of your solution
- 4. Thinking About the Process 1. Have a clear vision for the project 2. Have a rigorous process 3. Develop applications rapidly 4. Make it WORK first, then work RIGHT, THEN look pretty
- 5. Thinking About (Coding) the Solution 1. YAGNI (You Ain't Gonna Need It!) 2. DRY (Don't Repeat Yourself) 3. Embrace abstraction 4. DRITW (Don't Reinvent The Wheel) 5. Write code that does one thing well 6. Debugging is harder than writing code 7. Kaizen (leave it better than when you found it)
- 7. What is S.O.L.I.D? ● [S]ingle Responsibility Principle ● [O]pen/Closed Principle ● [L]iskov Substitution Principle ● [I]nterface Segregation Principle ● [D]ependency Inversion Principle
- 8. Single Responsibility Principle “A class should have one, and only one, reason to change”
- 9. Open/Closed Principle “You should be able to extend a classes behavior, without modifying it” In other words: Software entities (classes, modules, functions, etc.) must be opened for an extension, but closed for modification
- 10. Liskov Substitution Principle “Derived classes must be substitutable for their base classes”
- 11. Interface Segregation Principle “Make fine grained interfaces that are client specific” In other words: Many specific interfaces are better than a general interface
- 12. Dependency Inversion Principle “Depend on abstractions, not on concretions” Definition of this principle into two sub-items: ● 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.
- 14. Basic Types of Duplications 1. Data 2. Type 3. Algorithm These duplications happen unintentionally or because we don’t know how to prevent or get rid of it. We can prevent unintentional duplications by simply rechecking what we did.
- 15. Data Duplication Most basic and common type of duplication. Easily recognizable.
- 16. Type Duplication In many cases where the difference between two methods is only the type in which they operate on.
- 17. Algorithm Duplication Most difficult one and can not easily done without an understanding of the program.
- 18. Steps to Eliminate Duplicates Nothing new …. all these steps can be found in earlier points. 1. Single responsibility principle (First principle in SOLID) 2. DRY (Don’t Repeat yourself) 3. DRITW (Don’t Reinvent The Wheel) 4. Make it WORK first, then work RIGHT, THEN look pretty
- 20. Why Naming Conventions? To maintain, ● Readability ● Understandability ● Maintainability Each organization has its own syntax specific standards
- 21. Mobisec Best Practices ● Variable naming ● Function Naming ● Programming Standards
- 22. Variable naming ● Variable names should be meaningful and pronounceable. For example appcnt Vs appCounter. ● Specific words should not be used like equals, compare, data. ● Don't use same variable for different purposes in a method. ● Don't use _ to declare a variable name, Use camel casing. For example, employeeName is better than employee_name
- 23. Function naming ● Function names should be meaningful and pronounceable. ● Avoid pointless function names. For example myFunc(), procedure(). ● Don’t say one thing and do another. ● Function names should have a verb.
- 24. Programming Standards ● Use Camel Case (aka Upper Camel Case) for classes: VelocityResponseWriter ● Use Lower Case for packages: com.company.project.ui ● Use Mixed Case (aka Lower Camel Case) for variables: studentName ● Use Upper Case for constants : MAX_PARAMETER_COUNT = 100 ● Use Camel Case for enum class names and Upper Case for enum values. ● Don't use '_' anywhere except constants and enum values (which are constants).
- 25. Questions….?
- 26. Reference ● https://www.vikingcodeschool.com/software-engineering-basics/basic- principles-of-software-engineering ● https://mari-azevedo.medium.com/s-o-l-i-d-principles-what-are-they-and- why-projects-should-use-them-50b85e4aa8b6 ● https://itnext.io/solid-principles-explanation-and-examples-715b975dcad4 ● https://dev.to/danialmalik/a-beginner-s-guide-to-clean-code-part1-naming- conventions-139l ● https://medium.com/swlh/javascript-best-practices-variable-naming- conventions-ea121ca389c5 ● https://medium.com/wix-engineering/naming-convention-8-basic-rules-for- any-piece-of-code-c4c5f65b0c09 ● https://dzone.com/articles/best-practices-variable-and ● https://simpleprogrammer.com/types-of-duplication-in-code/
- 27. Thank You…..