{"id":340,"date":"2023-11-15T21:53:07","date_gmt":"2023-11-15T20:53:07","guid":{"rendered":"https:\/\/archicode.be\/?p=340"},"modified":"2023-11-15T22:04:16","modified_gmt":"2023-11-15T21:04:16","slug":"single-responsibility-principle-clearn-architecture","status":"publish","type":"post","link":"https:\/\/archicode.be\/index.php\/2023\/11\/15\/single-responsibility-principle-clearn-architecture\/","title":{"rendered":"Single Responsibility Principle (Clean Architecture)"},"content":{"rendered":"\n<p>When talking about patterns, almost everyone can name the SOLID pattern (Single Responsability, Open\/Close, Liskov Substitution, Interface Segregation and Dependency Inversion).  The Single Reponsibility is one of the most important principle for clean code but it&#8217;s also very important for clean architecture.  Let&#8217;s explore this <\/p>\n\n\n\n<p>The SRP states that a class should have <strong>one, and only one, reason to change<\/strong>. In other words, a class should encapsulate a single responsibility or functionality. Let\u2019s break down what this means:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Reason to Change<\/strong>: When we say \u201creason to change,\u201d we refer to any modification that might occur in the future. It could be due to a change in business requirements, a bug fix, or an enhancement. Each reason for change corresponds to a specific responsibility.<\/li>\n\n\n\n<li><strong>Class Independence<\/strong>: By adhering to the SRP, we ensure that each class focuses on a distinct aspect of the system. This independence has several benefits:\n<ul class=\"wp-block-list\">\n<li><strong>Maintainability<\/strong>: When a class has a single responsibility, it becomes easier to understand, modify, and maintain. Changes related to that responsibility won\u2019t affect other parts of the system.<\/li>\n\n\n\n<li><strong>Testability<\/strong>: Isolating responsibilities allows us to write focused unit tests. We can verify each responsibility independently.<\/li>\n\n\n\n<li><strong>Flexibility<\/strong>: If a requirement changes, we only need to modify the relevant class. Other classes remain unaffected.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Example<\/h3>\n\n\n\n<p>Imagine a module responsible for compiling and printing a report. According to the SRP:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If the content of the report changes (e.g., new fields, formatting), it\u2019s a valid reason to modify the module.<\/li>\n\n\n\n<li>However, if the report\u2019s printing mechanism changes (e.g., switching from PDF to HTML), that\u2019s a separate responsibility.<\/li>\n<\/ul>\n\n\n\n<p>By adhering to the SRP, we\u2019d separate these responsibilities into distinct classes or modules. This way, changes related to content or printing won\u2019t intertwine.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Understanding the SRP<\/h2>\n\n\n\n<p>This is somehow a bit remote from the common understanding of the SRP (A class should have only one responsbility, or that a class should do one and only one thing).  The reason of change as being the question to ask whether the class follows the SRP is a very interesting take on the pattern.<\/p>\n\n\n\n<p>If we apply this to a library, we can see that if the library has multiple reasons to change, then it might be a good idea to separate it into smaller libraries.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Maintenability<\/h2>\n\n\n\n<p>The idea behind all this remains the maintenability and ensuring that the cost of any change will remain minimal.  That is often the most underestimated cost of a project.  Since applications often live far longer than expected, reducing the cost of change is a must.<\/p>\n\n\n\n<p>Having libraries that have been developed with the SRP in mind will also be much easier to migrate or rewrite when comes the inevitable time when the application needs to be updated or rewritten.<\/p>\n\n\n\n<p>Keeping this in mind will also greatly facilitate the use of the Strangler Fig Pattern<sup data-fn=\"cc84316a-46a9-43a3-bc8b-30ef5b8f8f7c\" class=\"fn\"><a href=\"#cc84316a-46a9-43a3-bc8b-30ef5b8f8f7c\" id=\"cc84316a-46a9-43a3-bc8b-30ef5b8f8f7c-link\">1<\/a><\/sup><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>The SRP is a fundamental principle that promotes modular, maintainable, and robust software. Applying it ensures that our codebase remains adaptable and resilient to future changes.<\/p>\n\n\n\n<p>Remember: <strong>A class should have one, and only one, reason to change.<\/strong><\/p>\n\n\n\n<p>For more in-depth exploration of Clean Architecture and other SOLID principles, I recommend reading Robert C. Martin <sup data-fn=\"4ca3117a-7835-42dd-961a-c020aea15723\" class=\"fn\"><a href=\"#4ca3117a-7835-42dd-961a-c020aea15723\" id=\"4ca3117a-7835-42dd-961a-c020aea15723-link\">2<\/a><\/sup>. <\/p>\n\n\n\n<p><strong><em>Happy writing! \ud83d\ude80<\/em><\/strong><\/p>\n\n\n<ol class=\"wp-block-footnotes\"><li id=\"cc84316a-46a9-43a3-bc8b-30ef5b8f8f7c\"><a href=\"https:\/\/martinfowler.com\/bliki\/StranglerFigApplication.html\">StranglerFigAppl<\/a><a href=\"https:\/\/martinfowler.com\/bliki\/StranglerFigApplication.html\" target=\"_blank\" rel=\"noreferrer noopener\">i<\/a><a href=\"https:\/\/martinfowler.com\/bliki\/StranglerFigApplication.html\">cation (martinfowler.com)<\/a> <a href=\"#cc84316a-46a9-43a3-bc8b-30ef5b8f8f7c-link\" aria-label=\"Jump to footnote reference 1\">\u21a9\ufe0e<\/a><\/li><li id=\"4ca3117a-7835-42dd-961a-c020aea15723\"><a href=\"https:\/\/amzn.eu\/d\/4L44eIN\" target=\"_blank\" rel=\"noreferrer noopener\">Clean Architecture &#8211; Robert C. Martin<\/a> <a href=\"#4ca3117a-7835-42dd-961a-c020aea15723-link\" aria-label=\"Jump to footnote reference 2\">\u21a9\ufe0e<\/a><\/li><\/ol>","protected":false},"excerpt":{"rendered":"<p>When talking about patterns, almost everyone can name the SOLID pattern (Single Responsability, Open\/Close, Liskov Substitution, Interface Segregation and Dependency Inversion). The Single Reponsibility is one of the most important principle for clean code but it&#8217;s also very important for clean architecture. Let&#8217;s explore this The SRP states that a class should have one, and&#8230;<\/p>\n","protected":false},"author":1,"featured_media":343,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_newsletter_tier_id":0,"footnotes":"[{\"content\":\"<a href=\\\"https:\/\/martinfowler.com\/bliki\/StranglerFigApplication.html\\\">StranglerFigAppl<\/a><a href=\\\"https:\/\/martinfowler.com\/bliki\/StranglerFigApplication.html\\\" target=\\\"_blank\\\" rel=\\\"noreferrer noopener\\\">i<\/a><a href=\\\"https:\/\/martinfowler.com\/bliki\/StranglerFigApplication.html\\\">cation (martinfowler.com)<\/a>\",\"id\":\"cc84316a-46a9-43a3-bc8b-30ef5b8f8f7c\"},{\"content\":\"<a href=\\\"https:\/\/amzn.eu\/d\/4L44eIN\\\" target=\\\"_blank\\\" rel=\\\"noreferrer noopener\\\">Clean Architecture - Robert C. Martin<\/a>\",\"id\":\"4ca3117a-7835-42dd-961a-c020aea15723\"}]","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[1],"tags":[],"class_list":["post-340","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/archicode.be\/wp-content\/uploads\/2023\/11\/8a4f15b6-f5a9-4579-a2aa-6b95d588c817.jpg","jetpack-related-posts":[{"id":267,"url":"https:\/\/archicode.be\/index.php\/2023\/05\/05\/single-responsability-vs-interface-segregation\/","url_meta":{"origin":340,"position":0},"title":"Single responsability vs Interface segregation","author":"Hakim","date":"May 5, 2023","format":false,"excerpt":"I stumbled upon a Reddit post forwarding an article about how single responsability and interface segregation would be essentially the same. I obviously disagreed but by reading the comments, it appeared that the differences between the two aren't that clear for some Let's start with the single responsability. It means\u2026","rel":"","context":"In \"patterns\"","block_context":{"text":"patterns","link":"https:\/\/archicode.be\/index.php\/tag\/patterns\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/archicode.be\/wp-content\/uploads\/2023\/05\/1_VI8o7tE-jtcFp4Z837KJIQ-1.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/archicode.be\/wp-content\/uploads\/2023\/05\/1_VI8o7tE-jtcFp4Z837KJIQ-1.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/archicode.be\/wp-content\/uploads\/2023\/05\/1_VI8o7tE-jtcFp4Z837KJIQ-1.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/archicode.be\/wp-content\/uploads\/2023\/05\/1_VI8o7tE-jtcFp4Z837KJIQ-1.jpg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/archicode.be\/wp-content\/uploads\/2023\/05\/1_VI8o7tE-jtcFp4Z837KJIQ-1.jpg?resize=1050%2C600&ssl=1 3x"},"classes":[]},{"id":353,"url":"https:\/\/archicode.be\/index.php\/2023\/12\/03\/the-reuse-release-equivalence-principle-a-key-to-modular-design\/","url_meta":{"origin":340,"position":1},"title":"The Reuse\/Release Equivalence Principle: A Key to Modular Design","author":"Hakim","date":"December 3, 2023","format":false,"excerpt":"One of the challenges of software development is to create reusable and maintainable code. Reusable code can reduce duplication, improve quality, and save time and resources. Maintainable code is code that is easy to adapt, easy to correct and where those adaptation and change do not break any other part\u2026","rel":"","context":"Similar post","block_context":{"text":"Similar post","link":""},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":366,"url":"https:\/\/archicode.be\/index.php\/2024\/05\/11\/understanding-inject-in-blazor-components\/","url_meta":{"origin":340,"position":2},"title":"Understanding @inject in Blazor Components","author":"Hakim","date":"May 11, 2024","format":false,"excerpt":"Blazor, Microsoft\u2019s framework for building interactive client-side web UI with .NET, offers a robust solution for dependency injection (DI) in the form of the\u00a0@inject\u00a0directive. This powerful feature allows developers to inject services directly into their components, promoting a clean and modular architecture. What is Dependency Injection? Dependency Injection (DI) is\u2026","rel":"","context":"In &quot;.NET&quot;","block_context":{"text":".NET","link":"https:\/\/archicode.be\/index.php\/category\/net\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":349,"url":"https:\/\/archicode.be\/index.php\/2023\/11\/25\/use-case-pattern\/","url_meta":{"origin":340,"position":3},"title":"Use Case Pattern","author":"Hakim","date":"November 25, 2023","format":false,"excerpt":"The Use Case Pattern is a way of organizing the business logic of an application into a set of use cases. Each use case represents a specific action that a user can perform within the system. For example, in an e-commerce application, a use case might be \u201cPlace an Order\u201d\u2026","rel":"","context":"Similar post","block_context":{"text":"Similar post","link":""},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":324,"url":"https:\/\/archicode.be\/index.php\/2023\/11\/07\/how-to-use-feature-flags-in-blazor\/","url_meta":{"origin":340,"position":4},"title":"How to use Feature Flags in Blazor","author":"Hakim","date":"November 7, 2023","format":false,"excerpt":"Feature flags are a way of controlling the availability and behavior of features in your application without changing the code. They can help you with testing, experimentation, and gradual rollout of new functionality. Blazor is a framework for building interactive web UIs using C# and .NET. In this blog post,\u2026","rel":"","context":"Similar post","block_context":{"text":"Similar post","link":""},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/archicode.be\/wp-content\/uploads\/2023\/11\/4b6f8d86-a588-4313-8cc9-4c41a90aaae5.jpeg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/archicode.be\/wp-content\/uploads\/2023\/11\/4b6f8d86-a588-4313-8cc9-4c41a90aaae5.jpeg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/archicode.be\/wp-content\/uploads\/2023\/11\/4b6f8d86-a588-4313-8cc9-4c41a90aaae5.jpeg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/archicode.be\/wp-content\/uploads\/2023\/11\/4b6f8d86-a588-4313-8cc9-4c41a90aaae5.jpeg?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":164,"url":"https:\/\/archicode.be\/index.php\/2020\/07\/15\/working-with-legacy-databases\/","url_meta":{"origin":340,"position":5},"title":"Working with Legacy databases","author":"Hakim","date":"July 15, 2020","format":false,"excerpt":"It does not happen everyday that as a developer we start working on a greenfield project. On many occasions, we have maintenance work to do on existing projects or we are rewriting an old application into microservices. What happens during these brownfield projects is that we have to cope with\u2026","rel":"","context":"In &quot;.NET&quot;","block_context":{"text":".NET","link":"https:\/\/archicode.be\/index.php\/category\/net\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/archicode.be\/index.php\/wp-json\/wp\/v2\/posts\/340","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/archicode.be\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/archicode.be\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/archicode.be\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/archicode.be\/index.php\/wp-json\/wp\/v2\/comments?post=340"}],"version-history":[{"count":4,"href":"https:\/\/archicode.be\/index.php\/wp-json\/wp\/v2\/posts\/340\/revisions"}],"predecessor-version":[{"id":346,"href":"https:\/\/archicode.be\/index.php\/wp-json\/wp\/v2\/posts\/340\/revisions\/346"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/archicode.be\/index.php\/wp-json\/wp\/v2\/media\/343"}],"wp:attachment":[{"href":"https:\/\/archicode.be\/index.php\/wp-json\/wp\/v2\/media?parent=340"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/archicode.be\/index.php\/wp-json\/wp\/v2\/categories?post=340"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/archicode.be\/index.php\/wp-json\/wp\/v2\/tags?post=340"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}