SOLID Principles Gizem Türker iOS Developer @Machinarium Content: Introduction SOLID Principles Opposing Views Encapsulation, Abstraction Summary 2024 | JUG Tech Day Overview of

March of 1995 "The Ten Commandments of OO Programming" https://groups.google.com/g/comp.object/c/WICPDcXAMG8/m/EbGa2Vt-7q0J?pli=1

     Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle

Notes SOLID benefits are GREAT!          Ease of Maintenance and Reduced Costs Reusability Extensibility Testability Understandability and Readability Fewer Errors Flexibility and Adaptation Low Coupling Abstraction and Polymorphism

Notes Keep it simple! "A class should have only one reason to change. " Robert C. Martin Single Responsibility Principle

Notes Be open to add new features without changing the existing code! "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification." Robert C. Martin , Bertrand Meyer Open/ Closed Principle

Notes Swap out a class with its subclass without any hiccups in the program! "Objects in a program should be replaceable with instances of their subtypes without altering the correctness of the program." Barbara Liskov Liskov Substitution Principle

Notes Don't clutter a class with unnecessary methods — keep it sleek and relevant. "Clients should not be forced to depend upon interfaces they do not use." Robert C. Martin Interface Segregation Principle

Notes Build on ideas, not on the nitty- gritty details. Let high-level stuff float above the low-level details. "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." Robert C. Martin Dependency Inversion Principle

https://speakerdeck.com/lemiorhan/solid-is-dead-long-live-solid "Solid is not about good or simple design, it's about better design. Solid is not about understanding OOP better, it is about understanding the code (i.e. the design) better. Solid is not the goal, it is a tool, a guideline for using while refactoring software into a better design." Lemi Orhan SOLID is not about

Praesent eros est, consectetur a luctus id, cursus ac felis. https://www.bu.edu/sph/news/articles/2015/pasteurs-quadrant-and-population-heal/ Pasteur’s Quadrant

Praesent eros est, consectetur a luctus id, cursus ac felis. SOLID is about Cohesion Coupling      Modularity Ease of Maintenance Reusability Testability Responsiveness to Changes

Praesent eros est, consectetur a luctus id, cursus ac felis. SOLID is about Cohesion Coupling      Modularity Ease of Maintenance Reusability Testability Responsiveness to Changes      Flexibility Independent Development Ease of Debugging Reusability Adaptability to Changes

Single Responsibility Principle Praesent eros est, consectetur a luctus id, cursus ac felis.       SRP centers on the concept of separation of concerns. Each component should focus on a single concern. Without clear context, modules may interpret SRP differently. Recognizes the challenge in strictly adhering to "doing one thing." Cohesion can vary, indicating different levels of focus. SRP urges for components with clear, focused responsibilities. Seperation of Concers SRP leads to a more organized and flexible software architecture. Encourages careful consideration of each component's role within the system.

Notes Simplifies system complexity. Single Responsibility Principle Praesent eros est, consectetur a luctus id, cursus ac felis.     Emphasizes breaking down a software system into distinct components. Each component focuses on a specific functionality or concept. Simplifies system complexity. Encourages developers to critically assess and define the role of each component. Seperation of Concers Key principle Adherence to the Separation of Concerns is crucial for developing robust software. It serves as a guide for creating systems that are easier to understand, develop, and maintain.

Notes Aim to avoid changes that could lead to compatibility issues, bugs, or other regressions. Open/Closed Principle Praesent eros est, consectetur a luctus id, cursus ac felis.      Modules should be crafted for easy expansion and adaptability. Maintain a closed approach to modifications that threaten backward compatibility. Updating code doesn't mean a total overhaul; focus on adding new code for features. Aim to avoid changes that could lead to compatibility issues, bugs, or other regressions. Abstraction is key to decoupling modules, allowing for more flexible system architecture. Protect Variation By adhering to these principles, developers can create more robust, adaptable, and future-proof software systems. Encourages a disciplined approach to software development that values stability and extensibility.

Open/Closed Principle Praesent eros est, consectetur a luctus id, cursus ac felis.      The Open-Closed Principle (OCP) and Protect Variation Principle (PVP) serve as the foundation for many design patterns, emphasizing flexibility and stability in code. OCP, PVP, and the concept of information hiding are essentially the same principle expressed in different terms, focusing on safeguarding code from changes while allowing for growth. To shield the current code from changes, it's crucial to identify possible evolution points and encapsulate them within a stable interface. It's important to be clear about what aspects of the system can and cannot be extended to maintain control over the system's evolution. Indirection and Uniform Access contribute to a flexible design by abstracting the way data and functions are accessed. Protect Variation By embracing these principles and strategies, developers can create software that accommodates future growth and changes without requiring significant rewrites or risking existing functionality.

Notes To achieve a system with modular and flexible architecture, components need to be interchangeable. Liskov Substitution Principle Praesent eros est, consectetur a luctus id, cursus ac felis.     A class must reflect its name, embodying its intended functionality and responsibilities clearly. LSP emphasizes behavior predictability and consistency across code units, rather than focusing solely on inheritance. To achieve a system with modular and flexible architecture, components need to be interchangeable. Contracts define the expectations and responsibilities of each component, facilitating seamless integration and substitution. Inter Changeability By designing classes and components that strictly follow their defined roles and adhere to LSP, developers can create robust, adaptable software systems. Such systems benefit from greater ease of maintenance, scalability, and the ability to evolve without compromising existing functionalities.

Notes Although ISP may not provide explicit design directions, it acts as a crucial indicator of software health. Interface Segregation Principle Praesent eros est, consectetur a luctus id, cursus ac felis.      Aim to restrict the number of methods in a contract to those truly essential. Ensure abstractions are tightly focused and cohesive. Advocate for a design that avoids reliance on unused elements. Although ISP may not provide explicit design directions, it acts as a crucial indicator of software health. Following ISP principles leads to a streamlined, efficient software system tailored to specific user requirements. Limit Coupling Surface

Notes Focus on the least amount of information necessary for a component’s functionality. Interface Segregation Principle Praesent eros est, consectetur a luctus id, cursus ac felis.     Interfaces are traditional contract definitions, but dynamic languages utilize duck typing—type compatibility based on method and property presence. Emphasizes reducing unnecessary dependencies by assembling behaviors from independent, self-contained objects. Focus on the least amount of information necessary for a component’s functionality. Discourage the use of boolean or null parameters for enabling/disabling features, which can obscure function purposes. Limit Coupling Surface A thoughtful approach to defining contracts, favoring composition, and practicing minimalism in exposure can significantly enhance the maintainability, clarity, and flexibility of software systems. By adopting these practices, developers can create more robust, understandable, and scalable solutions.

Notes Advocates for a design where "abstractions should not depend on details, but details should depend on abstractions." Dependency Inversion Principle Praesent eros est, consectetur a luctus id, cursus ac felis.      High-level modules encapsulate critical domain or business logic, central to the application's purpose. Comprise integration and infrastructure code—elements that are more static and inflexible once implemented. Advocates for a design where "abstractions should not depend on details, but details should depend on abstractions." Proper structuring of dependencies ensures that high-level modules remain independent and adaptable. Keeps the core business logic insulated from technical complexities, promoting easier updates and scalability. Business Independence

SOLID PRINCIPLE INTERACTION DIAGRAM ISP SRP LSP DIP OCP

SOLID PRINCIPLE INTERACTION DIAGRAM ISP SRP LSP DIP OCP Limit Coupling Surface Inter changeability Separation of Concerns Business Independence Protected Variation

SOLID PRINCIPLE INTERACTION DIAGRAM ISP SRP LSP DIP OCP Limit Coupling Surface Inter changeability Separation of Concerns Business Independence Protected Variation Encapsulation Achieved through techniques like data encapsulation, information hiding, layered architecture, and more. Abstraction Utilized through parameterized system design, indirection, rule-based design, polymorphism, and others.

Gizem Türker, iOS Developer @Machinarium | indie Thank you for sharing your time with me! @gizemturkerdev

Books and Sources https://www.amazon.com/Software-Development-Principles-Patterns- Practices/dp/0135974445 https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity- Software/dp/0321125215 https://se.inf.ethz.ch/~meyer/publications/ https://www.cs.cmu.edu/~wing/ https://www.amazon.com/Object-Oriented-Software-Construction-Book-CD- ROM/dp/0136291554/ref=sr_1_1? crid=2X49SC18ANGGH&dib=eyJ2IjoiMSJ9.DPjO2f6z25s0qBskE2KXUXY9ZtP3ffzFZ1Kr74QpTbE.J6uHQc TMS9PhkY_roIhQRVjIENdVdmJfggFEeuaYLrU&dib_tag=se&keywords=Object- Oriented+Software+Construction+bertant+meyer&qid=1709368066&s=books&sprefix=object- oriented+software+construction+bertant+meye%2Cstripbooks-intl-ship%2C196&sr=1-1 https://speakerdeck.com/lemiorhan/solid-is-dead-long-live-solid