CODEWITHSUNDEEP
oopdesign-patternsarchitecturesolid-principles
Mehmet
Mehmet

Reputation: 755

Are there SOLID principle exceptions?

I try to apply SOLID principles in my project's class design. Are there any exceptions of SOLID principles? Do we HAVE to apply these principle DEFINITELY. For example I prepared a factory class.

class XAdderFactory
{
    private Person _person;

    public bool PersonHasNoRecords
    {
        get
        {
            return string.IsNullOrEmpty(_person.HasXRecords);
        }
    }

    public XAdderFactory(Person person)
    {
        this._person = person;
        if (PersonHasNoRecords)
        {
            new XListMakerAFactory(person);
        }
        else
        {
            new XListMakerB(person);
        }
    }
}

This class never conforms to the OCP.
New type list makers may be required in the future and I must add a new else if block.
Is my design bad?
Or are there exceptions of SOLID principles that are not mentioned too often?
I am not sure but my example complies with "Strategic Closure" of OCP? If you have another examples about SOLID exceptions,i think it would be helpful for designers.

Upvotes: 3

Views: 846

Answers (4)

Mehmet
Mehmet

Reputation: 755

I think i found the first thing that must be considered when writing codes.It is UNIT TESTS.Solid principles,design patterns etc are tools which helps to make unit tests.According to me any unexperiented programmer ( like me ) must apply UNIT TESTS with no exceptions.Test results already leads to programer toward better design.

Upvotes: -1

Supun Wijerathne
Supun Wijerathne

Reputation: 12948

SOLID principles (or any related principles) are guideline to avoid potential pitfalls/threats in a software project in terms of implementation and maintenance. And just following a principle blindly without knowing its reflection won't work at all.

As your example, I'll take OCP. The key concept behind OCP is that, if your project 100% complies with OCP, any other (may be by an outsider, new member) can do coding without looking at the current code but just looking at your api documentation (about method exposed) which really makes that person's life easy. And also no need to test the existing code again and again because no modifications will be happened for the existing code. But indeed there are some situations where we have to break OCP.

Ex:

  • A new requirement.(needs to implement inside an existing class),

  • A bug-fix

  • Limited framework support (any MVC framework) etc.

And also there might be some situations where we are breaking OCP knowing that it will not harm.

About the principles, you can have a simple analogy like this. When you walk on road there are lots of principles to follow as a pedestrian.

Ex:

  • Walk on left hand side. (So that you can see incoming vehicles)

  • Cross only on pedestrian-crossing (So that vehicles can see you clearly and they would stop).

Following them as far as possible definitely make you safe. But imagine a situation where there are no vehicles for miles on road, are you still searching for a pedestrian crossing to cross the road? no right? You know you are safe even its not a pedestrian crossing and you cross. And if there's a situation where the left hand side on the road is pretty muddy and cannot walk on, would you still go on mud just to follow the principle? no right. You'd rather walk on right hand side knowing the situation.

I think you got an idea about principles. :)

Upvotes: 1

Ravindra babu
Ravindra babu

Reputation: 38910

SOLID principles are just guidelines. You can arrive at solution to your problem with or with out using these principles.

Your main focus should be designing a solution to the problem rather than fitting your solution to a specific design pattern or principle.

If you really think that your class should not be modified, then only implement Open/Closed principle. Generally I don't see any issue in modification of existing Factory classes to add new types.

Below three principles are really useful for designing solution

Interface_segregation_principle: No client should be forced to depend on methods it does not use

Don't use fat interfaces in your code where implementation classes have to override un-used or un-related methods. Design granular interfaces and create classes, which implement these granular interfaces. Related SE question:

Interface Segregation Principle- Program to an interface

Dependency_inversion_principle: It's good principle. You should program to interface rather than implementation.

Liskov_substitution_principle : Use this principle if you need to change your implementation at run time dynamically. If your application does not change its implementation, you may not require this feature.

But Single_responsibility_principle is debatable among all five principles. Module may have single responsibility but designing a class catering to single responsibility will lead to hundreds/thousands of classes.

Upvotes: 2

Adi Levin
Adi Levin

Reputation: 5233

The Open-Closed principle is important and useful, but it is not something that should be applied blindly to all classes and all modules. In some cases, creating the abstractions that enable extensibility is just not worth it, because no extensions are expected. In other cases, we can anticipate that requirements will change, but we're not sure what kind of changes to expect, or we're not sure about the other requirements, so we prefer to postpone the decision, and begin with a simpler module implementation that does not respect OCP.

Upvotes: 3

Related Questions