Это плохой объектно-ориентированный дизайн? (производный класс используется в базовом классе)

Question

Может кто-нибудь сказать мне, если эта структура класса плохая?

class abstract Parent{
  public Child Foo(){
    return new Child();
  }
}

class Child : Parent{}

Я слышал, что ссылка на производный тип от базового типа всегда плоха и является признаком плохого дизайна. Может кто-нибудь сказать мне, почему это плохо или даже если это плохо?

Answer 1

Мне кажется, что вы используете базовый класс в качестве фабрики. Я бы рекомендовал против этого дизайна, потому что это уменьшает сцепление базового класса (это и базовый класс и фабрика) и увеличивает сцепление в базовом классе (поскольку это ссылается на производный класс (ы)).

Создайте класс фабрики отдельно от базового класса, и эти проблемы исчезнут.

Answer 2

Чтобы уточнить ответ dkackman, ваша фабрика в идеале должна возвращать объекты дочерних типов, но объявленные как родительский тип.

class Factory
{
    public Parent Foo()
    {
        return new Child();
    }

    public Parent Bar()
    {
        return new OtherChild();
    }
}

Основная идея заключается в том, что ваш вызывающий код не должен заботиться о том, какой дочерний класс он возвращает. Это одна концепция принципа подстановки Лискова.

Answer 3

На многих уровнях пахнет плохо. Просто спросите себя, что произойдет, если кто-то расширит ребенка; или это другой подкласс Parent (вместо Child).

Трудно представить случай, который оправдал бы этот дизайн (возможно, он существует, вы могли бы объяснить, чего вы пытаетесь достичь). (Вы знакомы с заводским образцом?)

В любом случае, чтобы получить разумное поведение для такого дизайна, я думаю, что следует принять и принять связь, даже попытаться применить ее, сделав класс Child окончательным / запечатанным (невозможно расширить) и думая, что оба класса как все. Но опять же, это может (почти наверняка) быть лучше достигнуто с другим более чистым дизайном.

Answer 4

Я не могу сказать ничего плохого в твоем дизайне. Чтобы сказать более конкретно, я должен знать вашу цель сделать это. Но какова бы ни была ваша цель, вы пропустите полиморфизм. Итак, подумайте с точки зрения клиентского кода, вы раскрываете детали суперкласса только для того, чтобы получить экземпляр подкласса. С какой стати мы это делаем? По крайней мере, я не. Помните принцип дизайна, мы всегда хотим очень сплоченный класс. Здесь вы нарушаете этот принцип, предоставляя фабричный метод для создания экземпляра подкласса.

Раджан