I have heard that the Liskov Substitution  Principle (LSP) is a fundamental principle of object oriented design. What is it and what are some examples of its use?

What is an example of the Liskov Substitution Principle?

What is the dependency inversion principle and why is it important?

Can you explain Liskov Substitution Principle (The &#39;L&#39; of SOLID) with a good C# example covering all aspects of the principle in a simplified way? If it is really possible.

Can you explain Liskov Substitution Principle with a good C# example?

What is the difference between Single Responsibility Principle and Separation of Concerns?

Difference between Single Responsibility Principle and Separation of Concerns

I have been doing SOLID in C# to a pretty extreme level in recent times and at some point realized I&#39;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&#39;m doing now, so I&#39;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&#39;t imagine what an architecture would look like that allows me to work in a similarly flexible fashion as in C#.

What I mean by this is that I have lots of small classes and interfaces that I compose using an IoC container, and I also use patterns like Decorator and Composite a lot. This results in an (in my opinion) very flexible and evolvable overall architecture that allows me to easily replace or extend functionality at any point of the application. Depending on how big the required change is, I might only need to write a new implementation of an interface, replace it in the IoC registration and be done. Even if the change is bigger, I can replace parts of the object graph while the rest of the application simply stands as it did before.

Now with F#, I don&#39;t have classes and interfaces (I know I can, but I think that&#39;s beside the point when I want to do actual functional programming), I don&#39;t have constructor injection, and I don&#39;t have IoC containers. I know I can do something like a Decorator pattern using higher order functions, but that doesn&#39;t quite seem to give me the same kind of flexibility and maintainability as classes with constructor injection.


Consider these C# types:

&lt;!-- language: c# --&gt;

    public class Dings
    {
        public string Lol { get; set; }

        public string Rofl { get; set; }
    }

    public interface IGetStuff
    {
        IEnumerable&lt;Dings&gt; For(Guid id);
    }

    public class AsdFilteringGetStuff : IGetStuff
    {
        private readonly IGetStuff _innerGetStuff;

        public AsdFilteringGetStuff(IGetStuff innerGetStuff)
        {
            this._innerGetStuff = innerGetStuff;
        }

        public IEnumerable&lt;Dings&gt; For(Guid id)
        {
            return this._innerGetStuff.For(id).Where(d =&gt; d.Lol == &quot;asd&quot;);
        }
    }

    public class GeneratingGetStuff : IGetStuff
    {
        public IEnumerable&lt;Dings&gt; For(Guid id)
        {
            IEnumerable&lt;Dings&gt; dingse;

            // somehow knows how to create correct dingse for the ID

            return dingse;
        }
    }

I&#39;ll tell my IoC container to resolve `AsdFilteringGetStuff` for `IGetStuff` and `GeneratingGetStuff` for its own dependency with that interface. Now if I need a different filter or remove the filter altogether, I may need the respective implementation of `IGetStuff` and then simply change the IoC registration. As long as the interface stays the same, I don&#39;t need to touch stuff **within** the application. OCP and LSP, enabled by DIP.

Now what do I do in F#?

&lt;!-- language-all: f# --&gt;

	type Dings (lol, rofl) =
	    member x.Lol = lol
	    member x.Rofl = rofl
	
	let GenerateDingse id =
	    // create list
	    
	let AsdFilteredDingse id =
	    GenerateDingse id |&gt; List.filter (fun x -&gt; x.Lol = &quot;asd&quot;)

I love how much less code this is, but I lose flexibility. Yes, I can call `AsdFilteredDingse` or `GenerateDingse` in the same place, because the types are the same - but how do I decide which one to call without hard coding it at the call site? Also, while these two functions are interchangeable, I now cannot replace the generator function inside `AsdFilteredDingse` without changing this function as well. This isn&#39;t very nice.

Next attempt:

	let GenerateDingse id =
	    // create list
	    
	let AsdFilteredDingse (generator : System.Guid -&gt; Dings list) id =
	    generator id |&gt; List.filter (fun x -&gt; x.Lol = &quot;asd&quot;)

Now I have composability by making AsdFilteredDingse a higher order function, but the two functions are not interchangeable anymore. On second thought, they probably shouldn&#39;t be anyway.

What else could I do? I could mimic the &quot;composition root&quot; concept from my C# SOLID in the last file of the F# project. Most files are just collections of functions, then I have some kind of &quot;registry&quot;, which replaces the IoC container, and finally there is one function that I call to actually run the application and that uses functions from the &quot;registry&quot;. In the &quot;registry&quot;, I know I need a function of type (Guid -&gt; Dings list), which I&#39;ll call `GetDingseForId`. This is the one I call, never the individual functions defined earlier.

For the decorator, the definition would be

	let GetDingseForId id = AsdFilteredDingse GenerateDingse

To remove the filter, I&#39;d change that to

	let GetDingseForId id = GenerateDingse

The downside(?) of this is that all functions that use other functions would sensibly have to be higher order functions, and my &quot;registry&quot; would have to map **all** functions that I use, because the actual functions defined earlier can&#39;t call any functions defined later, in particular not those from the &quot;registry&quot;. I might also run into circular dependency issues with the &quot;registry&quot; mappings.


Does any of this make sense? How do you really build an F# application to be maintainable and evolvable (not to mention testable)?

Application architecture/composition in F#

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?

I think I might have a wrong understanding of the principle. If I don&#39;t, I do not understand why is this principle good practice. Can someone explain this to me? Thanks

Liskov substitution principle - no overriding/virtual methods?

How does the [SOLID][1] &quot;Interface Segregation Principle&quot; differ from &quot;Single Responsibility Principle&quot;?

The Wikipedia [entry for SOLID says][2] that

&gt;ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them

However, to me that sounds like just applying the SRP to interfaces as well as classes. After all, if an interface is only responsible for just one conceptual thing, than you wouldn&#39;t be able to break it down further.

Am I missing something, or is ISP sort of redundant with SRP? If not, then what does ISP imply that SRP does not?


  [1]: http://en.wikipedia.org/wiki/Solid_(object-oriented_design)
  [2]: http://en.wikipedia.org/wiki/Interface_segregation_principle

In SOLID, what is the distinction between SRP and ISP? (Single Responsibility Principle and Interface Segregation Principle)

One of the most frequent arguments I hear for not adhering to the [SOLID][1] principles in object-oriented design is [YAGNI][2] (although the arguer often doesn&#39;t call it that): 

*&quot;It is OK that I put both feature X and feature Y into the same class. It is so simple why bother adding a new class (i.e. complexity).&quot;* 

*&quot;Yes, I can put all my business logic directly into the GUI code it is much easier and quicker. This will always be the only GUI and it is highly unlikely that significant new requirements will ever come in.&quot;*

*&quot;If in the unlikely case of new requirements my code gets too cluttered I still can refactor for the new requirement. So your &#39;What if you later need to…&#39; argument doesn&#39;t count.&quot;*

What would be your most convincing arguments against such practice? How can I really *show* that this is an expensive practice, especially to somebody that doesn&#39;t have too much experience in software development.

  [1]: http://en.wikipedia.org/wiki/SOLID
  [2]: http://en.wikipedia.org/wiki/YAGNI

SOLID vs. YAGNI

I&#39;m in a project that takes the Single Responsibility Principle pretty seriously. We have a lot of small classes and things are quite simple. However, we have an anemic domain model - there is no behaviour in any of our model classes, they are just property bags. This isn&#39;t a complaint about our design - it actually seems to work quite well

During design reviews, SRP is brought out whenever new behaviour is added to the system, and so new behaviour typically ends up in a new class. This keeps things very easily unit testable, but I am perplexed sometimes because it feels like pulling behaviour out of the place where it&#39;s relevant.

I&#39;m trying to improve my understanding of how to apply SRP properly. It seems to me that SRP is in opposition to adding business modelling behaviour that shares the same context to one object, because the object inevitably ends up either doing more than one related thing, or doing one thing but knowing multiple business rules that change the shape of its outputs.

If that is so, then it feels like the end result is an Anemic Domain Model, which is certainly the case in our project. Yet the Anemic Domain Model is an anti-pattern.

Can these two ideas coexist?  


EDIT: A couple of context related links:

SRP - [http://www.objectmentor.com/resources/articles/srp.pdf](https://web.archive.org/web/20150202200348/http://www.objectmentor.com/resources/articles/srp.pdf)  
Anemic Domain Model - http://martinfowler.com/bliki/AnemicDomainModel.html

I&#39;m not the kind of developer who just likes to find a prophet and follow what they say as gospel. So I don&#39;t provide links to these as a way of stating &quot;these are the rules&quot;, just as a source of definition of the two concepts.

Single Responsibility Principle vs Anemic Domain Model anti-pattern

I&#39;m trying to get into OOP lately, and I&#39;m having trouble with [SOLID][1] principles and design patterns. I see why people use them, and I really want to use them too, but I can&#39;t wrap my head around developing my classes to the specifications. I would really appreciate anything that would help my understanding of such.

  [1]: https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29


Can&#39;t seem to understand SOLID principles and design patterns

I am trying to learn the Single Responsibility Principle (SRP) but it is being quite difficult as I am having a huge difficult to figure out when and what I should remove from one class and where I should put/organize it.

I was googling around for some materials and code examples, but most materials I found, instead of making it easier to understand, made it hard to understand.

&gt; For example if I have a list of Users and from that List I have a
&gt; class Called Control that does lots of things like Send a greeting and
&gt; goodbye message when a user comes in/out, verify weather the user
&gt; should be able to enter or not and kick him, receive user commands and messages, etc.

From the example you don&#39;t need much to understand I am already doing too much into one class but yet I am not clear enough on how to split and reorganize it afterwards.

If I understand the SRP, I would have a class for joining the channel, for the greeting and goodbye, a class for user verification, a class for reading the commands, right ?

But where and how would I use the kick for example ?

I have the verification class so I am sure I would have all sort of user verification in there including weather or not a user should be kicked.

So the kick function would be inside the channel join class and be called if the verification fails ?

For example:

    public void UserJoin(User user)
    {
        if (verify.CanJoin(user))
        {
            messages.Greeting(user);
        }
        else
        {
            this.kick(user);
        }
    }

Would appreciate if you guys could lend me a hand here with easy to understand C# materials that are online and free or by showing me how I would be splitting the quoted example and if possible some sample codes, advice, etc.

Learning Single Responsibility Principle with C#

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?

All Solid Principles Solutions on Gang of Coders

Total of 12 Solid Principles Solutions