On the level of classes and above, a business logic responsibility is knowing how to do (or encapsulating) the business function: for example, a class knowing how to convert XML documents into JSON, or a service encapsulating the detection of fraud transactions. Here are some examples (they are derived from Adam Warski’s classification of objects in applications which he distilled in his thought-provoking post about dependency injection in Scala): Business Logicįor example, extracting a phone number from text, converting an XML document into JSON, or classifying a money transaction as fraud. Instead of defining a responsibility in abstract terms, it may be more intuitive to list the actual types of responsibilities. This phrase is a little more concrete, but it still doesn’t explain what a responsibility is and how small or large a responsibility should be for each particular method, class, module, or service. So, the SRP states that each component should have a single responsibility. The Single Responsibility Principle applies to the software that we develop on different levels: methods, classes, modules, and services (collectively, I’ll call all these things components later in this article). Let’s try to deconstruct it and look at what it actually means. The Single Responsibility Principle may feel a bit vague at first. This article explains the Single Responsibility Principle (SRP): what does it practically mean? And when and how should we apply it? What Does the Single Responsibility Principle Say?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |