Open/Closed is particularly vexing: software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification What does it mean to be extended but not modified? Does this principle lead inherently to deep, convoluted class hierarchies? There has been some discussion and criticism of SOLID and the Open/Closed principle recently, so we thought we’d share some of the Rescale development team’s experiences coming to an understanding of Open/Closed and using it to write classes whose behavior is easy to change. – site on fb: -Sławomir KowalskiĪsk, comment underneath at the end of the post, share it, rate it, whatever you want?.The SOLID principles of object-oriented design provide good guidelines for writing code that is easy to change, but for some of the principles, the motivation and value can be difficult to understand. Īnd NECESSERILY join the DevmanCommunity community on fb, part of the community is in one place ? Leave upvote and follow and wait for next articles :). If you recognise it as useful, share it with others so that others can also use it. This content also you can find on my blog Link to github with the whole code from this article: In the next lesson, as you probably guessing, there will be discuss SOLID principle, open-closed. "\nPrice of all products: " clientCart.PriceAllProducts) Ĭonsole.WriteLine("It's in my wallet: " (client.MyWallet - clientCart.PriceAllProducts) " PLN") "\nThe number of sweets in the cart: " clientCart.NumberCandys "\nNumber of drinks in the cart: " clientCart.NumberDrinks "\nOrder placed by: " client.FirstName " " client.LastName "\nThe number of products in the cart: " clientCart.GetProductsCount() Of course, you can probably improve something in every code, no matter how well it would be written, how easy it would be to read, if all the rules of programming were met, not only SOLID, you can always improve something.īut you will admit that this is a much better solution than the one in which the Single Responsibility principle does not apply.Īnd below the call in the Main function: namespace SingleResponsibilityĬlient client = new Client("Slawomir", "Kowalski", "81-198", MyWallet) ĬlientCart clientCart = new ClientCart() Public double SumProductsPrice(double priceproduct)Īnd whether it does not look better? We have specific classes and methods that are responsible for a specific part of the store’s logic, the code has become much more readable, easier to understand and modify, we also the names of classes and methods have been improved. Private void CheckTypeProducts(string typeproduct) Public void SaveTypeProducts(string typeproduct)Ĭonsole.WriteLine("This type of product is already in the cart!") Let’s move to practical examples, an example of a class that breaks the principle of a single responsibility is the one given in the introduction: class Products However, by creating many small classes, you increase readability, ease of expansion and, generally speaking, ease of managing the project code. Large classes are always harder to maintain, develop and refactorize, building large classes always sooner or later leads to problems such that if our project will be a class and will be responsible for everything in the future expansion of this class, changing its functionality will also affect completely different areas of this class, which in large projects? leads to the fact that they are simply impossible to expand and modify. This is the most important SOLID principle, thanks to it we will not have classes of monsters after 2000 lines ?, which will be responsible for everything, but we will have many small classes responsible for different parts of the program. The principle of single responsibility says that each class should be responsible for one specific thing, there should be only one reason to modify the class.
0 Comments
Leave a Reply. |