how to organize classes in ruby if they are literal subclasses

Question

I know that title didn't make sense, Im sorry! Its hard to word what I am trying to ask. I had trouble googling it for the same reason.

So this isn't even Ruby specific, but I am working in ruby and I am new to it, so bear with me.

So you have a class that is a document. Inside each document, you have sentences, and each sentence has words. Words will have properties, like "noun" or a count of how many times they are used in the document, etc.

I would like each of the elements, document, sentence, word be an object.

Now, if you think literally - sentences are in documents, and words are in sentences.

Should this be organized literally like this as well? Like inside the document class you will define and instantiate the sentence objects, and inside the sentence class you will define and instantiate the words?

Or, should everything be separate and reference each other? Like the word class would sit outside the sentence class but the sentence class would be able to instantiate and work with words?

This is a basic OOP question I guess, and I suppose you could argue to do it either way. What do you guys think?

Each sentence in the document could be stored in a hash of sentence objects inside the document object, and each word in the sentence could be stored in a hash of word objects inside the sentence.

I dont want to code myself into a corner here, thats why I am asking, plus I have wondered this before in other situations.

Thank you!

Answer 1

For languages that allow a class to be defined within the definition of another class, you could run into visibility problems where the internal class cannot be used by an outside class. In your case, if you think you might want to use one of these internal classes outside of the whole document-sentence-word system, then internal classes is not a good idea. In fact, I try to avoid using internal classes as a general rule, and only do it when the internal class is one that does not make sense in any other context except that of the containing class.

...so to answer your question: if it were me, I'd have them all as separate classes that reference each other.

Answer 2

You can create an anonymous class. You might even be able to control who has access to those anonymous classes by using access control on a method that creates / returns the anonymous class - I don't know. But I don't think it's something you really need.

Rather than totally prohibiting other parts of the code from using those classes, it'd probably be best to merely document that they're for internal use only. One way of indicating they're for internal use is to use namespaces.

If the class is named DocumentParser, then it sounds like a class everyone can use. However, if you have something named DocumentParser::Noun or DocumentParser::Sentence then they might realize that they may be using implementation details that shouldn't be relied upon.

Answer 3

Looks like you are mixing 2 concepts here: nesting objects and nesting classes. These are different things. Your objects, likely, need to be nested. However, your classes don't have to be nested. They might, but it's a matter of style (and some languages don't allow nested classes at all). Also, it depends on how you plan to use these classes. For example, in your case, do words have meaning as a separate concept? not just as a part of a sentence? If so, I would define Word as a separate class.