3

For instance, if I'm modeling a book collection and I want to be able to represent sets of books that come together (like an encyclopedia series), the sets may share a lot of properties that individual books would also have (author, publication date, title, etc.). In terms of naming the classes in an OOP context, would it be appropriate for the superclass to be called BookSet if a subclass would be something like IndividualBook, or is another word more appropriate?

3
  • 4
    Inheritance is for “is a” type of relations. Does it make sense to say: a book ‘is a’ set? No? Don’t use inheritance. Commented Sep 15, 2022 at 22:17
  • 3
    Especially since "Set" is somewhat confusing, you might want to call it "BookSeries", which matches the real world nomenclature better. For example. Patrick O'Brien writes the Aubrey–Maturin series, not the Aubrey–Maturin set. Commented Sep 16, 2022 at 5:54
  • How is named this "set" of books in the real world? Commented Sep 16, 2022 at 7:24

4 Answers 4

12

This is a semantical argument, not a technical one. Mathematicians will happily agree that a set can contain one number. Obviously, arrays and lists can have 1 item in them as well. There is no technical limitation here.

However, I suspect you are using the wrong name for the concept you're trying to describe. If this data applies to both individual books and book sets, you should find a unique name to describe and encapsulate their shared structure.

For example, LibraryItem. Then Book and BookSet can inherit (or implement) LibraryItem, which enables you to reuse the shared commonalities, but without any confusion in regards to a single book needing to be part of a set on its own.

Feel free to pick a different name than LibraryItem, there may be a contextually more appropriate name for your use case.

4
  • 3
    A set with one item is not the same as the item though. Commented Sep 16, 2022 at 5:57
  • 1
    @JacquesB A consistent system can be set up whereby singular items are always represented by a set of only said item. They're not equal, but they can be equivalent. Commented Sep 16, 2022 at 7:25
  • I’m planning a book series and the first book is finished. That should probably be a book series, distinguishable from a single book. Commented Sep 19, 2022 at 8:27
  • @gnasher729: There is no proven need to distinguish these, as the use case for the application is not made clear in the question. Could it be relevant? Maybe. But I don't quite see the value of wanting to already define a set when there is only one book released (and known about, since your idea is to not even mention any further books yet even if they havem't been released yet), at least not in a way that you only want this for specific cases and not just all books (which could always get a future sequel) at which point you again don't need to distinguish as it would apply to all books Commented Sep 19, 2022 at 14:10
1

Interpreting that in two ways.

Assuming that I understood it, (1) you want to give the base class a categorical name, like BookSet. As this clashes with with ~Set in standard libraries, it should be more like BookCategory. But the convention AbstractBook or BookBase or such is still better. The reader then will not need to digest the context you are specifying.

(2) More likely. If you want a hierarchy, where a work (book) might be a collection of smaller works even of different authors. Or you have a series of books, where in the e-book publishing these works are often small, and packed in one larger epub. I find Publication more palatable (normally with an ISBN number). However a Story (work) can be collectively in a publication, or in its own publication, or be republished. This would make a distinction between a physical publication and an intellectual story. It however also offers a chance: searching for a story you might find several publications. I think BookSet as straight inheritance will not work.

0

Object-orientation is about behavior, not data. Having common data is a really bad reason to create a superclass. Also, data should be always hidden in object-oriented designs, so you wouldn't even be able to use "common data" anyway.

If you have common data, find the common behavior instead, and create an object for that. Try not to use inheritance, define a separate object that does what you want, and include that in the books or wherever you need it.

1
  • 1
    In addition to this answer. Books, Series and Sagas are different things even when some of their properties match. I would approach this as different data structures. Book as the atomic one, Series a collection (composition|agreggation) of books of the same author and correlated stories and Saga as a collection of books with no strict relationship between them. Not even the author is always the same in Sagas. I would try (at all costs) to use names evoking native data types of my programming language, so I don't cause an ictus to my coworkers every time we have to speak about the subject. Commented Sep 16, 2022 at 11:53
0

It does not ... Domain Driven Design makes it very clear

Operation names should come from the UBIQUITOUS LANGUAGE or be introduced into it. Parameters and results should be domain objects.

The names in software should use the same terminology that is used in the real world domain.

As user949300 notes above, Set is not part of the domain language. Likewise, the attributes on a book, also wouldn't be called a set.

Therefore, it does not make sense to use the word Set as an umbrella term for both sets and individual items.

Now with respect to what the domain calls such a collection of books or their attributes ... that requires additional investigation to get the domain correct.

A place to start is with the English Language and Usage question on what to call a Group of Books

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.