Class that does not represent anything - is it correct?

Question

I am just designing my application and I am not sure if I understand SOLID and OOP correctly. Classes should do 1 thing and do it well but from the other hand they should represent real objects we work with.

In my case I do a feature extraction on a dataset and then I do a machine learning analysis. I assume that I could create three classes

1. FeatureExtractor
2. DataSet
3. Analyser

But the FeatureExtractor class doesnt represent anything, it does something what makes it more of a routine than a class. It will have just one function that will be used : extract_features()

Is it correct to create classes that do not represent one thing but do one thing?

EDIT: not sure if it matters but I'm using Python

And if extract_features() would look like that: is it worth to create a special class to hold that method?

def extract_features(df):
    extr = PhrasesExtractor()
    extr.build_vocabulary(df["Text"].tolist())

    sent = SentimentAnalyser()
    sent.load()

    df = add_features(df, extr.features)
    df = mark_features(df, extr.extract_features)
    df = drop_infrequent_features(df)
    df = another_processing1(df)
    df = another_processing2(df)
    df = another_processing3(df)
    df = set_sentiment(df, sent.get_sentiment)
    return df

Answer 1

Classes should do 1 thing and do it well

Yes, that is generally a good approach.

but from the other hand they should represent real object we work with.

No, that is a IMHO common misunderstanding. A good beginner's access to OOP is often "start with objects representing things from the real world", that is true.

However, you should not stop with this!

Classes can (and should) be used to structure your program in various ways. Modeling objects from the real world is one aspect of this, but not the only one. Creating modules or components for a specific task is another sensible use case for classes. A "feature extractor" is probably such a module, and even it contains only one public method extract_features(), I would be astonished if if does not also contain a lot of private methods and maybe some shared state. So having a class FeatureExtractor will introduce a natural location for these private methods.

Side note: in languages like Python which support a separate module concept one can also use a module FeatureExtractor for this, but in the context of this question, this is IMHO a negligible difference.

Moreover, a "feature extractor" can be imagined as "a person or bot which extracts features". That is an abstract "thing", maybe not a thing you will find in the real world, but the name itself is a useful abstraction, which gives everyone a notion of what the responsibility of that class is. So I disagree that this class does not "represent anything".

Answer 2

Doc Brown is spot-on: classes don’t need to represent real-world objects. They just need to be useful. Classes are fundamentally merely additional types, and what does int or string correspond to in the real world? They are abstract descriptions, not concrete, tangible things.

That said, your case is special. According to your description:

And if extract_features() would look like that: is it worth to create a special class to hold that method?

You absolutely right: if your code is as shown, there’s no use making it into a class. There’s a famous talk that argues that such uses of classes in Python are code smell, and that simple functions are often sufficient. Your case is a perfect example of this.

Overuse of classes is due to the fact that OOP became mainstream with Java in the 1990s. Unfortunately Java at the time lacked several modern language features (such as closures), which mean that many concepts were hard or impossible to express without the use of classes. For instance, it was impossible in Java until recently to have methods that carried state (i.e. closures). Instead, you had to write a class to carry the state, and which exposed a single method (called something like invoke).

Unfortunately this style of programming became popular far beyond Java (partly due to an influential software engineering book that’s otherwise very useful), even in languages that don’t require such workarounds.

In Python, classes are obviously a very important tool and should be used liberally. But they’re not the only tool, and there’s no reason to use them where they don’t make sense. It’s a common misconception that free functions have no place in OOP.

Answer 3

I am just designing my application and I am not sure if I understand SOLID and OOP correctly.

Been at this over 20 years and I'm not sure either.

Classes should do 1 thing and do it well

Hard to go wrong here.

they should represent real objects we work with.

Oh really? Let me introduce you to the single most popular and successful class of all time: String. We use it for text. And the real world object it represents is this:

Why no, not all programmers are obsessed with fishing. Here we are using something called a metaphor. It's OK to make models of things that don't really exist. It's the idea that must be clear. You're creating images in the minds of your readers. Those images don't have to be real. Just understood easily.

A good OOP design clusters messages (methods) around data (state) so that the reactions to those messages can vary depending on that data. If doing that models some real world thing, spiffy. If not, oh well. So long as it makes sense to the reader, it's fine.

Now sure, you could think of it like this:

but if you think this has to exist in the real world before you can make use of the metaphor, well your programming career is going to involve lots of arts and crafts.

Answer 4

Beware! Nowhere does SOLID say a class should only "do one thing". If that was the case, classes would only ever have a single method, and there wouldn't really be a difference between classes and functions.

SOLID says a class should represent a single responsibility. These are kind of like the responsibilites of persons in a team: The driver, the lawyer, the pickpocket, the graphic designer etc. Each of these persons can perform multiple (related) tasks, but all pertaining to a single responsibility.

The point of this is - if there is a change in the requirements, you ideally only need to modify a single class. This just makes the code easier to understand, easier to modify and reduces risk.

There is no rule that an an object should represent "a real thing". This is just cargo-cult lore since OO was initially invented for the use in simulations. But your program is not a simulation (few modern OO applications is), so this rule does not apply. As long as each class have a well-defined responsibility, you should be fine.

If a class really only have a single method and the class does not have any state, you could consider making it a stand-alone function. This is certaily fine and follows the KISS and YAGNI principles - no need to make a class if you can solve it with a function. On the other hand, if you have reason to believe you might need internal state or multiple implementations, you might as well make it a class up-front. You will have to use your best judgment here.

Answer 5

Is it correct to create classes that do not represent one thing but do one thing?

In general that is OK.

Without a little bit more specific description what the FeatureExtractor class is supposed to do exactly it is hard to tell.

Anyways, even if the FeatureExtractor exposes only a public extract_features() function, I could think of configuring it with a Strategy class, wich determines how exactly the extraction should be done.

Another example is a class with a Template function.

And there are more Behavioral Design Patterns, which are based on class models.

---

As you added some code for clarification.

And if extract_features() would look like that: is it worth to create a special class to hold that method?

The line

 sent = SentimentAnalyser()

exactly comprises what I meant that you could configure a class with a Strategy.

If you have an interface for that SentimentAnalyser class, you can pass it to the FeatureExtractor class at its point of construction, instead of directly coupling to that specific implementation in your function.

Answer 6

Patterns and all the fancy language/concepts aside: what you have stumbled across is a Job or a Batch Process.

At the end of the day, even a pure OOP program needs to somehow be driven by something, to actually perform work; there must be an entry point somehow. In the MVC pattern, for example, the "C"ontroller receives click etc. events from the GUI and then orchestrates the other components. In classic command line tools, a "main" function would do the same.

Is it correct to create classes that do not represent one thing but do one thing?

Your class represents an entity that does something and orchestrates everything else. You can name it Controller, Job, Main or whatever comes to mind.

And if extract_features() would look like that: is it worth to create a special class to hold that method?

That depends on circumstances (and I'm not familiar with the usual way this is done in Python). If this is just a small one-shot command line tool, then a method instead of a class should be fine. The first version of your program can get away with a method, for sure. If, later, you find that you end up with dozens of such methods, maybe even with global variables mixed in, then it's time to refactor into classes.

Answer 7

We can think of OOP as modelling the behaviour of a system. Note that the system doesn't have to exist in the 'real world', although real-world metaphors can sometimes be useful (e.g. "pipelines", "factories", etc.).

If our desired system is too complicated to model all at once, we can break it down into smaller pieces and model those (the "problem domain"), which may involve breaking down further, and so on until we get to pieces whose behaviour matches (more or less) that of some built-in language object like a number, a string, a list, etc.

Once we have those simple pieces, we can combine them together to describe the behaviour of larger pieces, which we can combine together into even larger pieces, and so on until we can describe all of the components of the domain that are needed for a whole system.

It is this "combining together" phase where we might write some classes. We write classes when there isn't an existing object which behaves in the way we want. For example, our domain might contain "foos", collections of foos called "bars", and collections of bars called "bazs". We might notice that foos are simple enough to model with strings, so we do that. We find that bars require their contents to obey some particular constraint which doesn't match anything Python provides, in which case we might write a new class to enforce this constraint. Perhaps bazs have no such peculiarities, so we can just represent them with a list.

Note that we could write a new class for every one of those components (foos, bars and bazs), but we don't need to if there's already something with the correct behaviour. In particular, for a class to be useful it needs to 'provide' something (data, methods, constants, subclasses, etc.), so even if we have many layers of custom classes we must eventually use some built-in feature; for example, if we wrote a new class for foos it would probably just contain a string, so why not forget the foo class and have the bar class contain those strings instead? Keep in mind that classes are also a built-in object, they're just a particularly flexible one.

Once we have our domain model, we can take some particular instances of those pieces and arrange them into a "simulation" of the particular system that we want to model (e.g. "a machine learning system for ...").

Once we have this simulation, we can run it and hey presto, we have a working (simulation of a) machine learning system for ... (or whatever else we were modelling).

---

Now, in your particular situation you're trying to model the behaviour of a "feature extractor" component. The question is, are there any built-in objects which behave like a "feature extractor", or will you need to break it up into simpler things? It looks like feature extractors behave very much like function objects, so I think you'd be fine to use those as your model.

---

One thing to keep in mind when learning about these sorts of concepts is that different languages can provide different built-in features and objects (and, of course, some don't even use terminology like "objects"!). Hence solutions which make sense in one language might be less useful in another (this can even apply to different versions of the same language!).

Historically, a lot of the OOP literature (especially "design patterns") has focused on Java, which is quite different from Python. For example, Java classes are not objects, Java didn't have function objects until very recently, Java has strict type checking (which encourages interfaces and subclassing) whilst Python encourages duck-typing, Java doesn't have module objects, Java integers/floats/etc. aren't objects, meta-programming/introspection in Java requires "reflection", and so on.

I'm not trying to pick on Java (as another example, a lot of OOP theory revolves around Smalltalk, which is again very different from Python), I'm just trying to point out that we must think very carefully about the context and constraints in which solutions were developed, and whether that matches the situation we're in.

In your case, a function object seems like a good choice. If you're wondering why some "best practice" guideline doesn't mention function objects as a possible solution, it might simply be because those guidelines were written for old versions of Java!

Answer 8

Pragmatically speaking, when I have a "miscellaneous thing that does something important and should be separate", and it doesn't have a clear home, I put it in a Utilities section and use that as my naming convention. ie. FeatureExtractionUtility.

Forget about the number of methods in a class; a single method today may need to grow to five methods tomorrow. What matters is a clear and consistent organisational structure, such as a utilities area for miscellaneous collections of functions.