What STRONG Principles are violated?

Question

Introduction

---

I am working on my master's thesis on inheritance issues and indicators that show that there is an inheritance problem.

As in the following example:

Example

---

public static String getAnimalNoise(Animal animal) { if (animal instanceof Dog) return "Woof"; if (animal instanceof Cat) return "Miau"; return ""; } 

The method returns String "Woof" if the given instance of Animal is Dog and "Miau" if it is Cat . An empty line, because some animals do not make noise at all.

Therefore, the correct solution for this should be to use polymorphism using the getNoise method in the Animal class.

I have analyzed various indicators of inheritance problems and I want to say if some of them violate the SOLID principle.

I thought the above example violates:

• Single Responsibility Principle (SRP)
• Open / Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Dependency Inversion Principle (DIP)

But I'm not sure if this is true for everyone.

I thought:

VIOLATIONS OF THE PRINCIPLE

---

SRP violation

Because conditional statements generally violate SRP, because, like a case case switch or more than one if-else statement, more than one responsibility is considered.

There are two cases, so there are several reasons for changing the method.

OCP violation

Because if a new animal is added, a new method must be added to the method so the method is not close to changes.

LSP VIOLATION

Each branch performs different actions depending on the subtype of animals. What do I consider violating LSP ?! I know an example of a rectangle and a square and getArea, but these for example, I thought it was suitable for a violation.

VIOLATION DISPLAY

Conditional operators take a dependency, which means that the operators depend on the details, not on the abstractions that violate DIP.

Question:

---

So, the question is, what are the true principles for this example, the truly violated and correct arguments?

Answer 1

SRP Since conditional statements generally violate SRP because, as a case switch statement or more than one if-else statement, more than one responsibility is considered. It exists in two cases, so there are several reasons for changing the method.

I strongly disagree. SRP is intended for interpretation with a pinch of salt. Read Uncle Bob's article on it here - he came up with this principle.

I will give important bits:

What determines the cause of the change?

This principle applies to people.

When you write a software module, you want to make sure that when requesting changes, these changes can come only from one person or, rather, from one closely related group of people representing a single, narrowly defined business function. You want to isolate your modules from the complexities of the organization as a whole and design your systems in such a way that each module meets (meets) the needs of only one business function.

[...] how you think of this principle, remember that people are the cause of change. These are people who require change. And you don’t want to confuse these people or yourself by mixing code that many different people care for various reasons.

---

OCP . If you add a new animal, the new method must be added to the method, so the method is not suitable for modifications.

Correctly. The method involves a certain set of implementations and will not be able to process new ones without change.

---

LSP Each branch performs various actions depending on the subtype of animals. What do I consider violating LSP ?!

It violates the LSP, but for a different reason. If I passed the giraffe, I would get an unexpected result, an empty string. This means that the method is not suitable for any subtype of Animal .

---

DIP Conditional operators accept a dependency, which means that the operators depend on the details, not on abstractions that violate DIP.

Technically true, but this is just a side effect of breaking the other two principles above. This is not the core of the problem.

---

Remember that principles are not rules, so do not be too strict / literal in interpreting them. Pragmatism and understanding why a principle is needed are key.

Answer 2

I do not agree that your sample code violates the LSP. LSP is defined as follows:

Let Φ (x) be a property provable with respect to objects x of type T. Then Φ (y) must be true for objects y of type S, where S is a subtype of T.

Given the two conclusions from Animal, namely Dog and Cat and your getAnimalNoise method, you do not decide on any provable property of a particular object. Your method decides which noise should be returned, not the objects themselves.

So, imagine that you can set the number of legs for an animal.

 Animal a = new Animal() a.setLegFront(2); a.setLegRear(2); 

And if your Dog rewrites it like this:

  class Dog extends Animal { public void setFrontLegs(int legs) { this.frontLegs = legs; this.rearLegs = legs + 2; } public void setRearLegs(int legs) { // do nothing here for demonstration purposes } } 

If you now have a factory returning Animal

 Animal createAnimal() { return new Dog(); } Animal a = createAnimal(); a.setFrontLegs(2); a.setRearLegs(2); 

And you call the setFront/setRearLegs , expect the results to be 2 and 2, but in fact the result is completely different, namely 2 and 4. Thus, this example is closely related to the general LSP example with squares and rectangles, But for me this is a more accurate example of a violation of provable properties than in your example.

Update for other principles

I agree with you that other principles are also violated, but for SRP I agree with @dcastro.