Подкласс или не подкласс - PullRequest
       14

Подкласс или не подкласс

5 голосов
/ 30 декабря 2010

У меня есть три объекта;Действие, вопрос и риск.Все они содержат множество общих переменных / атрибутов (например: Описание, заголовок, Срок выполнения, Поднял и т. Д.) И некоторые конкретные поля (риск имеет вероятность).Вопрос:

  1. Должен ли я создать 3 отдельных класса Action, Risk и Issue, каждый из которых содержит повторяющиеся поля.Abstract_Item ", содержащий эти поля и операции над ними, а затем имеет подкласс Action, Risk и Issue Abstract_Item.Это будет соответствовать принципу СУХОЙ.

Ответы [ 7 ]

5 голосов
/ 30 декабря 2010

Моя перспектива

Скажем, если вы использовали наследование.За период у вас появились новые атрибуты, которые являются общими только для Действие и Выпуск , но не Риск .Как вы справитесь с этим?Если вы поместите их в родительский элемент, тогда Risk наследует вещи, которые не имеют значения (стук принципа подстановки Лискова?).Если вы поместите затем в Action и Risk отдельно, то вы нарушите DRY, первоначальную причину, по которой вы начали наследование.Дело в том, что Наследственность для повторного использования - это плохо.Если нет «есть-а», то лучше не использовать его, а когда вы сомневаетесь, тогда нет реального «есть-а».

Мои предпочтения

Есть другие способы достижения СУХОГО, как показано в примере кода ниже.С этим добавлением новых свойств может быть Common2 , добавление нового поведения будет новым CommonBehavior2 , если они неприменимы ко всем 3 классам;если это так, просто измените существующие Common и CommonBehavior

public class Common implements CommonBehavior
{
    String Description;
    String title;

    public void f() {}
}

public interface CommonBehavior
{
    void f();
}

public class Action implements CommonBehavior
{
    private Common delegate;

    public void f()
    {
        delegate.f();
    }
}

Также посмотрите на мой ответ на аналогичный вопрос с другим практическим примером Шаблон проектирования надобавить новый класс

2 голосов
/ 30 декабря 2010

Да, придерживаться DRY, как правило, очень хорошая идея , за исключением , если у классов очень и очень разное использование (т.е. и яблоки, и машины могут быть красными, но я бы не стал выводить их обоих из базовый класс называется ProbablyRed). В вашем случае, однако, я бы определенно выбрал базовый класс, поскольку описанные вами реализации (Action, Issue, Risk) кажутся неким бизнес-правилом с очень похожей семантикой.

0 голосов
/ 21 мая 2012

Не делайте подклассы только потому, что объекты совместно используют некоторые данные или операции. Рассматривайте композицию как способ по умолчанию следовать за DRY.

В вашем конкретном случае создавайте родительский класс, только если вашобъекты на самом деле связаны, то есть есть семантическая связь «есть» с родительским классом.Например, если Action, Issue и Risk являются объектами Ticket.

0 голосов
/ 01 января 2011

Я думаю, что я ответил на тот же вопрос здесь

Когда создавать класс против установки логического флага?

0 голосов
/ 30 декабря 2010

Другой аспект может стать видимым, если вы посмотрите на варианты использования, возможно, имеющие дело с различными подгруппами свойств.

Если, например, "to label", "срок исполнения" и "поднято" используются в todo-подобном приложении, а другие свойства "Action" и "Risk" будут преобладать при работе над этой задачей, вы можетерассмотрим совокупность, скажем, Task (метка, срок выполнения, ...) и Topic, которая является полиморфной ссылкой на такие вещи, как Action, Issue или что-либо еще, когда-нибудь возникнет

0 голосов
/ 30 декабря 2010

Абстрактный родительский класс звучит как путь.Это также сделает возможным или проще (в зависимости от вашего языка) реализацию и использование функций, которые действуют на любой из трех элементов.Например, у вас может быть функция «Получить список всех элементов, созданных {user}».

0 голосов
/ 30 декабря 2010

Вы, кажется, отвечаете на это сами.Как вы говорите, СУХОЙ.

...