CODEWITHSUNDEEP
c#oopsolid-principlessingle-responsibility-principle
Pa3k.m
Pa3k.m

Reputation: 1166

Am I following the SRP with this structure?

I am trying to write a plugin for Autocad, and there, they have these Extension Dictionaries where you can save data into an Autocad object so that when you close a drawing file, the saved data persists.

Now I need 4 functions to manipulate the extension dictionary:

currently, what I have is I have an ExtensionDictionaryManager.cs that is partial broken down into 4 .cs files like this:

partial class ExtensionDictionaryManager
{
    public bool Exist() {...}
}

partial class ExtensionDictionaryManager
{
    public bool Create() {...}
}

partial class ExtensionDictionaryManager
{
    public bool Set() {...}
}

partial class ExtensionDictionaryManager
{
    public bool Get() {...}
}

Does this follow the Single Responsibility Principle? Or should I break it down even more into ExtensionDictionaryCreator, ExtensionDictionaryChecker, ExtensionDictionarySetter and ExtensionDictionaryGetter?

My concern is if I did break it into absolute single responsibilities, not grouping related functionalities together, and doing it consistently throughout my program, I would end up with so many objects.

Which would be the right way to do this?

Upvotes: 2

Views: 178

Answers (1)

SomeBody
SomeBody

Reputation: 8761

The SRP is difficult to handle. See for example a Message class. Should this class contain a Send() method? Can a method send itself? Or should there be another class MessageSender?

Some people use the SRP only to make classes smaller and smaller, which might ultimately lead to classes containing only one method. But methods that belong togehter should stay together. A good help is how to decide what should be in the same class is: If I have to change a feature, often I have to change several methods. These methods should be in the same class. If I change always the same two classes at the same time, these classes maybe should be united. If I change only one part of a class, or the other, but never both parts at the same time, the class should be split. See also https://hackernoon.com/you-dont-understand-the-single-responsibility-principle-abfdd005b137

Coming back to the example with the message: If the mechanism of sending the message is completely unrelated to the data that the message contains, two classes Message and MessageSender might be better. If the format of the message is strongly linked to how to send the message, it might be better to have a single class. But this is always some subjective consideration.

And for your code: I would leave it in one class. See for example List<T>: This is one class for manipulating the list, and not a ListAdder<T>, ListInserter<T>, ListRemover<T>, ... If your autocad changes, you will have to change the the algorithm of checking whether something exists, of creating, and so on, all at the same time. That's why they belong into one class.

Upvotes: 3

Related Questions