![]() This leads us to break “fat” interfaces into smaller ones, grouping similar methods under the one interface. In practice, this means that class should not implement interfaces with methods which it doesn’t need. ISP states that no client should be forced to depend on methods it does not use. But, if you think about it, there is a certain similarity between SRP and Interface Segregation Principle(ISP). Ok, so we can now better understand the principle that each class should cover one functionality. ![]() But also, we added more flexibility in our code. We separated responsibilities and hence made our code more readable, and maintainable. So what we have done is, moved code that is responsible for manipulation with database into the new class, and left just the code that drives workflow in the original function. Where Data = ", toValue, entity.CurrentValue), _sqlConnection))Ĭonsole.WriteLine( " Failed to modify data") Using ( var updateCommand = new SqlCommand( String.Format ![]() Var reader = readCommand.ExecuteReader() Using ( var readCommand = new SqlCommand( " select * from Entity", sqlConnection)) Using ( var sqlConnection = new SqlConnection(connectionString)) So how does that look in practice? Let’s take a look at the example: So, I wanted to go more in-depth of this principle and its different variations, and give a little bit more insight into the various applications of this concept. Still, SRP is a concept that is so powerful and applicable that, if you look closely, it still permeates a lot of aspects of a software developer. Separating responsibilities from one another, and finding a way for them to coexist, is much of what software design is really about. This can be due to legacy code, or lack of motivation, or lack of domain knowledge or simply due to our natural tendency to join responsibilities. Now, this sounds pretty logical and straightforward, but over the years in the industry, I can see that this is hard to get right on point. “Reason to change” in that definition pretty much means – responsibility, meaning that every software module or class should encapsulate single functionality that software provides. The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change. In the first of the five principles, Single Responsibility Principle, Uncle Bob combined ideas from two papers On the Criteria To Be Used in Decomposing Systems into Modules and On the role of scientific thought and gives a definition of SRP as it follows: These principles are the backbone of Object Oriented Design and hold a key to crafting high quality and easily maintainable code. SOLID is one astute acronym, in which each letter stands for a different principle: Martin, most commonly known as Uncle Bob, came up with the first five principles of Object Oriented Programming and Design – SOLID principles.
0 Comments
Leave a Reply. |