![]() Let’s take a look at the improved design: Next, the battery charge validation logic should be moved to the Battery class since the battery itself knows better than anything how to validate its own state. Now let’s reconsider our design, remembering that each class should have not more than one reason for change.įirst, the logic for actually handling the Starter’s ignition process should be moved to the Starter class and the Starter itself should contain a Start() method which will be invoked by the Engine’s Start() method. The key point here is that the Engine class has more than one responsibility and per the Single Responsibility Principle this is not good. If either of these things changed we would have to modify our Engine class to accommodate the change(s). What if we installed a different type of Starter and the logic associated with how it actually works internally changed?.What if we installed a different type of Battery and the logic associated with verifying its charge state changed?.Any logic associated with how to start the engine is contained within the Start() method as is the “validation” of determining whether or not the battery is charged. ![]() But when we look in the Engine class and read the Start() method, we can see that there may be more than one reason why the Engine class would have to be changed. It makes sense that we would have an Engine class, a Starter class, a Battery class, and an IgnitionResult enum. Let’s think about this code as it is written. we would put code here to handle the logic for checking ![]() Public IgnitionResult Start(Starter starter, Battery battery) If we didn’t understand the Single Responsibility Principle, we might build our classes similarly to this:īased on the design shown above, let’s consider this code: Let’s suppose that we wanted to represent an Engine’s ignition/starter functionality in a few C# classes. If we don’t make this assumption and declare it as a “rule”, the scope of our design changes could make the illustration of the concept overly-complicated and I really want to keep it simple here and discuss the principle in the simplest terms possible.įurthermore we are going to use our design in this post to continue to apply SOLID design principles one by one. IMPORTANT: For the sake of simplicity, we are going to assume that for this example, the one hard rule that will not ever change is the fact that there will always be a Starter object and a Battery object associated with an Engine. If you would like to learn more about how a starter works, here is a great article □ Haha. When it is energized, it forces the engine to turn over and the combustion process begins. In case you don’t know, your engine has a component called a starter that is attached to the engine, has electrical connections to allow it to draw power from the battery, and when you engage your ignition switch via a key or pushbutton, the starter is energized. So let’s consider an automobile engine from the standpoint of the starter mechanism. ![]() This is how our applications should be written. An engine is maintainable because the various parts/components are easily removed and replaced. The engine in your automobile is a marvel of modern engineering and has been designed to function optimally with each component having minimal dependencies on other components. I am most definitely NOT a mechanic, and I do not claim to know a great deal about combustion engines, but I think that a subset of an engine’s functionality is a great way to illustrate the SOLID design principles. Seems pretty simple, right? When you consider it for what it is, it is pretty simple. The greater the number of responsibilities, the more reasons a class will have for change. The Single Responsibility Principle states that a class should have only one reason for change. In this post we are going to dive into this design principle with a very simple example in C#. In our introduction to the SOLID Design Principles, we mentioned the Single Responsibility Principle as one of the five principles specified. Single Responsibility Principle in C# – SOLID Design Principles – Part 1
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |