solid-principles | 易学教程

Breaking SOLID Principles in multiple implementation of an Interface

阅读更多关于 Breaking SOLID Principles in multiple implementation of an Interface

问题 I am facing a problem with dependency inversion in a factory method and it is also breaking Open Closed principle. My code looks like below codes public interface IWriter { void WriteToStorage(string data); } public class FileWriter : IWriter { public void WriteToStorage(string data) { //write to file } } public class DBWriter : IWriter { public void WriteToStorage(string data) { //write to DB } } Now I an using a factory class to solve the object creation. It look like below code public

What is the reasoning behind the Interface Segregation Principle?

阅读更多关于 What is the reasoning behind the Interface Segregation Principle?

The Interface Segregation Principle (ISP) says that many client specific interfaces are better than one general purpose interface. Why is this important? ISP states that: Clients should not be forced to depend on methods that they do not use. ISP relates to important characteristics - cohesion and coupling . Ideally your components must be highly tailored. It improves code robustness and maintainability. Enforcing ISP gives you following bonuses: High cohesion - better understandability, robustness Low coupling - better maintainability, high resistance to changes If you want to learn more

C# return type covariance and Liskov substitution principle

阅读更多关于 C# return type covariance and Liskov substitution principle

问题 I'm trying to understand Covariance and LSP. From this question I can see C# does not support return type covariance. However Liskov substitution principle imposes covariance on return type. Does it mean it is impossible to apply this principle in C# ? Or did I missunderstand something ? 回答1: C# can still apply the Liskov substitution principle. Consider: public class Base1 { } public class Derived1 : Base1 { } public class Base2 { public virtual Base1 Method() { return new Base1(); } }

Application architecture/composition in F#

阅读更多关于 Application architecture/composition in F#

问题 I have been doing SOLID in C# to a pretty extreme level in recent times and at some point realized I'm essentially not doing much else than composing functions nowadays. And after I recently started looking at F# again, I figured that it would probably be the much more appropriate choice of language for much of what I'm doing now, so I'd like to try and port a real world C# project to F# as a proof of concept. I think I could pull off the actual code (in a very un-idiomatic fashion), but I

Can anyone provide an example of the Liskov Substitution Principle (LSP) using Vehicles?

阅读更多关于 Can anyone provide an example of the Liskov Substitution Principle (LSP) using Vehicles?

The Liskov Substitution Principle states that a subtype should be substitutable for that type (without altering the correctness of the program). Can someone please provide an example of this principle in the domain of vehicles (automotives)? Can someone please provide an example of a violation of this principle in the domain of vehicles? I've read about the square/rectangle example, but I think that an example with vehicles will give me a better understanding of the concept. For me, this 1996 Quote from Uncle Bob ( Robert C Martin ) summarises the LSP best: Functions that use pointers or

Can't seem to understand SOLID principles and design patterns [closed]

阅读更多关于 Can't seem to understand SOLID principles and design patterns [closed]

I'm trying to get into OOP lately, and I'm having trouble with SOLID principles and design patterns. I see why people use them, and I really want to use them too, but I can't wrap my head around developing my classes to the specifications. I would really appreciate anything that would help my understanding of such. Uri I've taken a class in college that spent two weeks around design patters, and read the Gang of Four book to no avail. Understanding what each pattern served for and how to use them to fit my problems was very hard for me, a developer that didn't have much experience in OO

Interface Segregation Principle- Program to an interface

阅读更多关于 Interface Segregation Principle- Program to an interface

I was reading about SOLID and other design principles. I thought ISP was the same as "Program to an interface, not an implementation". But it looks like these are different principles? Is there a difference? Pete Stensønes ISP is focused on the idea of each interface representing one discrete and cohesive behavior. That is, each logical group of things an object should do would map to a single specific interface. A class might want to do several things, but each thing would map to a specific interface representing that behavior. The idea is each interface is very focused. Nazar Merza Robert

What is the meaning and reasoning behind the Open/Closed Principle?

阅读更多关于 What is the meaning and reasoning behind the Open/Closed Principle?

The Open/Closed Principle states that software entities (classes, modules, etc.) should be open for extension, but closed for modification. What does this mean, and why is it an important principle of good object-oriented design? Specifically, it is about a "Holy Grail" of design in OOP of making an entity extensible enough (through its individual design or through its participation in the architecture) to support future unforseen changes without rewriting its code (and sometimes even without re-compiling **). Some ways to do this include Polymorphism/Inheritance, Composition, Inversion of

Difference between Single Responsibility Principle and Separation of Concerns

阅读更多关于 Difference between Single Responsibility Principle and Separation of Concerns

问题 What is the difference between Single Responsibility Principle and Separation of Concerns? 回答1: Single Responsibility Principle (SRP)- give each class just one reason to change; and “Reason to change” == “responsibility”. In example: Invoice class does not have a responsibility to print itself. Separation of Concerns (since 1974). Concern == feature of system. Taking care of each of the concerns: for each one concern, other concerns are irrelevant. Hiding implementation of behavior. From here

Liskov substitution principle - no overriding/virtual methods?

阅读更多关于 Liskov substitution principle - no overriding/virtual methods?

问题 My understanding of the Liskov substitution principle is that some property of the base class that is true or some implemented behaviour of the base class, should be true for the derived class as well. I guess this would mean when a method is defined in a base class, it should never be overrided in the derived class - since then substituting the base class instead of the derived class would give different results. I guess this would also mean, having (non-pure) virtual methods is a bad thing?