Я использую Java в качестве примера, но это скорее общий вопрос, связанный с дизайном ООП.
Давайте возьмем IOException в Java в качестве примера. Почему существует класс FileNotFoundException? Не должен ли быть экземпляр IOException, где причина - FileNotFound? Я бы сказал, что FileNotFoundException является экземпляром IOException. Где это заканчивается? FileNotFoundButOnlyCheckedOnceException, FileNotFoundNoMatterHowHardITriedException..?
Я также видел код в проектах, в которых я работал, где существуют классы, такие как FirstLineReader и LastLineReader. Для меня такие классы фактически представляют экземпляры, но я вижу такой дизайн во многих местах. Посмотрите на исходный код Spring Framework, например, сотни таких классов, где каждый раз, когда я вижу один, я вижу экземпляр вместо чертежа. Разве классы не предназначены для чертежей?
То, что я пытаюсь спросить, заключается в том, как вы принимаете решение между этими двумя очень простыми вариантами:
Вариант 1:
enum DogBreed {
Bulldog, Poodle;
}
class Dog {
DogBreed dogBreed;
public Dog(DogBreed dogBreed) {
this.dogBreed = dogBreed;
}
}
Вариант 2:
class Dog {}
class Bulldog extends Dog {
}
class Poodle extends Dog {
}
Первый параметр предоставляет вызывающему абоненту требование настроить экземпляр, который он создает. Во втором варианте класс уже представляет сам экземпляр (как я вижу, что может быть совершенно неправильным..).
Если вы согласны с тем, что эти классы представляют экземпляры вместо чертежей, вы бы сказали, что хорошей практикой является создание классов, представляющих экземпляры, или это совершенно неправильно, так как я смотрю на это, и мой оператор "классы, представляющие экземпляры", просто нагрузка ерунды?
