I understand that there are several questions on OOD; this one is not a duplicate (I hope) because of its specific nature – can a functionality that process data be a class?
First, some background.
This came up from a discussion my supervisor had with me. I was supposed to write a video loading class. His idea was to have a single Video class that loads itself.
I thought through it and came up with a Video class that stores the codec, filename, frame per second and more importantly the byte arrays, and a VideoLoader class that takes a filename, a reference to the Video class and then populate it.
My supervisor said this is not correct. “A class should always have a state”. I assume he meant private members here. “The VideoLoader is just a bunch of processing functions. It shouldn’t be a class”. I argue that I am doing decoupling. The VideoLoader in the future could have an abstract base class in case we are using different libraries (currently FFMPEG) to load videos.
It still kind of bother me, though. OOD always describes finding the verbs and the nouns, and ‘processing-only classes’ rarely come out from OOD design. Are there guidelines in OOD for this?
I agree with your approach.
Consider your VideoLoader a helper class that is used to instantiate or populate as you say the instances of Video. It is a part of a good design to separate responsibilities and not put it all into one entity. Anyway, in many object-oriented frameworks it is not possible to have standalone methods without wrapper classes.
If you wish to please your supervisor you could put a Load method in your Video class and make it the only way to instantiate videos.
The way you are doing it actually has a term – Factory pattern.
Have a look here: Factory method pattern. This is exactly what you are doing. You use a factory to instantiate video classes of potentially various types (codec-dependent or else).