The document discusses the SOLID principles for software architecture, emphasizing the importance of single responsibility and the other principles to avoid 'spaghetti code.' It highlights the benefits of following these principles, such as improved code clarity, reusability, and readability, while acknowledging challenges in implementation. Overall, it underscores the necessity for organized, maintainable code structures in software development.

1. SOLID Principles for Software Architectsaka No More Spaghetti Code

2. Ricardo Wilkins SharePoint Solutions ArchitectApp Dev (.NET; embedded)

3. Web Dev (ASP, PHP)

4. Application Lifecycle Management (TFS)

5. Technical Training

6. Blog: rixbits.blogspot.com

7. : @ricardo303Single Responsibility PrincipleOpen / Close PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion Principle

8. Single Responsibility PrincipleOpen / Close PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion Principle

9. avoid Code Rot

10. How can we tell when our code is rotting?

11. RigidityDesign is hard to change

12. FragilityDesign is easy to break

13. ImmobilityDesign is hard to reuse

14. ViscosityDesign makes it hard to do the right thing

16. Definition“Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.”“Classes should have one responsibility - one reason to change.”

18. Example

21. Arguments against SRP?

22. Argument Against SRP“Too many classes and too difficult to understand the BIG PICTURE.” There are no more moving parts in a system with many small pieces than that with a few large pieces. The benefits outweigh this argument. Consistency, good names, and documentation make this a mute point.

23. What are some of the benefits?Reuse - If all your classes follow the srp, you are more likely to reuse some of themClarity - Your code is cleaner as your classes don’t do unexpected thingsNaming - As all your classes have a single responsibility, choosing a good name is easyReadability - Due to the clarity, better names and shorter files the readability is improved greatly.

24. SIDEBARWorkflows:1 per content typeVs1 workflow to rule them all

26. A module should be opentoextensibility,butclosedfor modification.

28. Example