-1

The more I read about the Single Responsibility Principle the less I see a class as an object type, but rather as a servant that does something.

For example, let us suppose we have a new requirement that we need to generate a Pdf file where we write data we get from a Bill class. I would create a class for this. Do I name the class PdfFile or PdfGenerator?

To my OO perspective a new Pdf file object has just emerged so I would name it PdfFile, but it doesn't make much sense to talk about responsibilities of a PdfFile object.

Edit: Instead of "in what basis do I name classes" this question could as well be "in what basis do I create classes".

3

I would create a class for this. Do I name the class PdfFile or PdfGenerator?

What the question boils down to is answering what the class represents. There are several ways to look at this problem. They somewhat overlap in your particular case, but in some situations one approach makes more sense than the others, so I'm listing them all.

Does the class represent:

  • ... the pdf file itself? (filepath, content, size, metadata, ...)
  • ... the logic on how to create a pdf file? (data parsing, value printing, formatting, ...)

If the former, use PdfFile. If the latter, use PdfGenerator.

Another way to distinguish these is to ask yourself whether your intended class' main purpose is to:

  • ...contain data (PdfFile)
  • ...perform an action ("generates a file" => PdfGenerator).

Important:
I'm not implying that a class can't both contain data and perform operations. Of course it can, and probably will. But if you were to describe this class' responsibility to someone using a single sentence, would you say "this class is ..." or "this class does ..."?

The more I read about the Single Responsibility Principle the less I see a class as an object type, but rather as a servant that does something.

If you think of the class as "doing something", then you do indeed name it after the "job" that it has. Classes like these tend to predominantly contain methods.

But what about classes that predominantly contain properties? Would you say that e.g. this class does something?

public class Student
{
    public string Name { get; set; }
    public int ID { get; set; }
    public DateTime DateOfBirth { get; set; }
}

I wouldn't. I'd say that this class is (or represents) some information that we wanted to retain, but this class doesn't do anything by itself. In this case, you name the class for the data/entity it represents, hence why I called it Student and not StudentInformationStorage or something similarly contrived.

To my OO perspective a new Pdf file object has just emerged so I would name it PdfFile

To put it this way: a baker produces bread, but a baker isn't a bread himself. So why would a class that produces a pdf file inherently be considered a pdf file in and of itself? It doesn't make sense. Are you the code you write?

The question on how to name your class isn't dependent on whether a pdf file was created or not, the question is how this class (or, more specifically, a class instance) relates to this pdf file. Does it represent the created file, or did it merely create the file?

"in what basis do I name classes" this question could as well be "in what basis do I create classes"

That question is about as broad as asking "how do I do OOP?", which is much too broad for StackExchange. If you want to get into the subject matter to such a degree, I recommend digging into source material, whether that's a book, an online course, tutorial, or simply browsing GitHub (or other repositories) to see how others do it (whichever works best for you).

2

Name things based on what the using code ends up looking like. Pick names that keep people from having to look inside to understand. For example:

If I construct something like this.

Bill bill = new Bill(new PdfBillPresenter(new File("some/filename"))));

And later, whenever I like, I do this:

bill.save();

Do you need to see more code than this to have a good idea of what's doing what? That's the sign of a good name.

If the structure seems odd it's cause I'm following this.

4
  • I'm not saying your answer is wrong (because I do agree with it), but it may be too terse for an OOP beginner (which I surmise OP is). I suspect that given OP's confusion on class naming, using an example with the same name for variables as for classes is going to raise more questions/confusion than it answers/resolves. – Flater Apr 22 '20 at 22:30
  • Questions and confusion are the first step to improvement. Upvoted – Steve Chamaillard Apr 23 '20 at 7:29
  • 1
    This answer illustrates the single biggest thing I struggle with when teaching OOP to other people. OOP is selfless. It's not about the class itself. It's about how that object is used. The object only lives to serve another. Only in serving another will you know what to name the class, and how to design it's public interface. It seems simple to me, but this is a conceptual mountain range to climb for people new to OOP. – Greg Burghardt Apr 23 '20 at 12:26
  • @GregBurghardt on that point one of the most enlightening things I’ve studied is the difference between orchestration and choreography. People selling you an orchestrator love to brag about having one place to control everything. Sound familiar? – candied_orange Apr 23 '20 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.