Jump to content

How to refactor class with SRP/SOLID principles in mind?


dennis-fedco

Recommended Posts

I am refactoring a class that has multiple responsibilities.  After reading Single_responsibility_principle, I am still not sure, how to factor out the class into its aspects.

The methods of the class are (summarized):

  • class constructor
  • Calculate {General, A, B}
  • Convert {General, A, B}
  • Load {General, C, D}
  • Save {General, C, D}

By General I mean i.e. load() function that can load A or B or both depending on the circumstances, and by A or B I mean more specific loadA(), or loadB().

My specific questions in regards to SRP is:

  1. Do `load()` and `save()` belong to different classes, because they can in theory change at different times for different reasons, or can/should I put them into the same class, because loading/saving can be considered as "database operations" and if one changes so *may* the other, i.e. adding a new attribute to whatever is being saved/loaded?
  2. How do I organize the classes anyway?  i.e. something like this?
    class CalculateGeneral() {};
    class CalculateA() extends CalculateGeneral {};
    class CalculateB() extends CalculateGeneral {};
    
    class ConvertGeneral() {};
    class ConvertA() extends ConvertGeneral {};
    class ConvertB() extends ConvertGeneral {};
    
    class LoadSaveGeneral() {};
    class LoadC() extends LoadSaveGeneral{};
    class LoadD() extends LoadSaveGeneral{};
    

Woah that's 9 classes out of 1 that it is now..

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.