ООП. Выбор объектов

Объектно-ориентированный дизайн не выполняется изолированно. Вопрос, который вы должны задать, - что мое конкретное приложение должно делать (если вообще что-либо) с классом Drink? Ответ и, следовательно, дизайн будут отличаться от приложения к приложению. Способ номер 1 потерпеть неудачу в ОО - это попытаться построить идеальную платоническую иерархию классов - такие вещи существуют только в идеальных платоновских мирах и бесполезны в реальном мире, в котором мы живем.

Там два решения проблемы сахара. Первый - добавить подкласс, такой как HotDrinks, который содержит addSugar и addMilk, например:

                 Drink
                  /  \
          HotDrink    Juice
           /   \
        Tea     Coffee

Проблема в том, что это становится беспорядочным, если их много.

Другое решение - добавить интерфейсы. Каждый класс может реализовывать ноль или более интерфейсов. Итак, у вас есть интерфейсы ISweetened и ICowPowerEnabled. Где и Tea, и Coffee реализуют интерфейсы ISweetened и ICowPowerEnabled.

Этот PDF-файл может вам очень помочь, и он идеально подходит для вашего примера:

Шаблон декоратора

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

Вы должны быть осторожны, чтобы не связывать функцию с базовым классом только потому, что она является общей для всех производных классов. Подумайте лучше, если эту функцию можно извлечь и применить к другим, несвязанным объектам - вы обнаружите, что многие методы в вашем базовом классе «реального мира» на самом деле могут принадлежать разным интерфейсам.

Например, если вы «добавляете сахар» к напиток сегодня, вы можете решить добавить его в блин позже. И тогда вы можете закончить тем, что ваш код будет запрашивать напиток во многих местах, используя AddSugar и различные другие несвязанные методы - это может быть сложно рефакторинг.

Если ваш класс умеет что-то делать, то он может реализовать интерфейс, независимо от того, что это за класс на самом деле. Например:

interface IAcceptSugar
{
    void AddSugar();
}

public class Tea : IAcceptSugar { ... }
public class Coffee : IAcceptSugar { ... }
public class Pancake : IAcceptSugar { ... }
public class SugarAddict : IAcceptSugar { ... }

Использование интерфейса для запроса конкретной функции у объекта, который фактически ее реализует, помогает вам создавать в высшей степени независимый код.

public void Sweeten(List<IAcceptSugar> items)
{
   if (this.MustGetRidOfAllThisSugar)
   {
       // I want to get rid of my sugar, and
       // frankly, I don't care what you guys
       // do with it

       foreach(IAcceptSugar item in items)
          item.AddSugar();
   }
}

Ваш код также становится легче тестировать. Чем проще интерфейс, тем легче вы протестируете потребителей этого интерфейса.

[Edit]

Возможно, я не совсем понял, поэтому поясню: если AddSugar () выполняет то же самое для группы производных объектов, вы будете Конечно, реализовать это в своем базовом классе. Но в этом примере мы сказали, что Drink не всегда должен реализовывать IAcceptSugar.

Таким образом, мы можем получить общий класс:

 public class DrinkWithSugar : Drink, IAcceptSugar { ... }

, который будет реализовывать AddSugar () таким же образом для группы напитков.

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

Мораль такова: ваша иерархия может измениться, пока ваши интерфейсы остаются прежними.

Две вещи, которые могут иметь значение:

1) Нил Баттерворт поднимает очень важное различие между моделью реального мира в некотором контексте и самим реальным миром. Объектно-ориентированный дизайн не зря иногда называют объектно-ориентированным моделированием. Модель касается только «интересных» аспектов реального мира. Что интересно, зависит от контекста вашего приложения.

2) Предпочитайте композицию наследованию . Напиток имеет свойства объема и температуры (которые в контексте моделирования могут быть связаны с человеческим восприятием, то есть очень холодным, холодным, теплым, горячим) и состоит из ингредиентов (воды, чая, кофе, молока, сахара, ароматизаторов). Обратите внимание, он не наследуется от ингредиентов, он сделан из них.

Если вы новичок, я бы не стал беспокоиться о том, что ваш шаблон дизайна не будет идеальным. Фактически многие возразят, что не существует идеального шаблона проектирования: P

Что касается вашего примера, я бы, вероятно, создал абстрактный класс для напитков, таких как чай и кофе (потому что они имеют схожие атрибуты). И попробуйте сделать так, чтобы у класса drink было очень мало атрибутов и методов. Вода и сок могут быть подклассом абстрактного класса напитков.

Используйте шаблон декоратора .

Одна из распространенных ошибок новичков в объектно-ориентированном программировании состоит в том, что они не понимают, что наследование используется для двух разных целей: полиморфизма и повторного использования. В языках с единичным наследованием обычно приходится жертвовать частью повторного использования и просто делать полиморфизм.

Другая ошибка - чрезмерное использование наследования. Хотя может показаться хорошей идеей начать создание красивой иерархии наследования, лучше подождать, пока не возникнет полиморфная проблема, а затем создать наследование.

Если вам дается проблема создать классы для 4 разных виды напитков, сделать 4 разных типа без наследства. Если вам задали задачу, которая гласит: «Хорошо, теперь мы хотим дать человеку любой из этих напитков и распечатать, что он выпил», то это идеальное использование полиморфизма. Добавьте интерфейс или абстрактный базовый класс с функцией drink () . Компиляция push, обратите внимание, что все 5 классов говорят, что функция не реализована, реализуйте все 5 функций, нажмите компиляцию, и все готово.

Чтобы ответить на ваш вопрос, ваш вопрос о добавлении молока или сахара проблема, я предполагаю, что вы ' повторяется то, что вы хотите передать объект Drinkable Person , но Drinkable не содержит addMilk или ] addSugar . Эту проблему можно решить двумя или более способами, один из которых - очень плохой.

Плохой способ: передать Drinkable человеку и ввести тип осмотрите и наложите на объект, чтобы получить обратно чай или сок .

void prepare (Drinkable drink)
{
  if (drink is Juice)
  {
    Juice juice_drink = (Juick) drink;
    juice_drink.thing();
  }
}

В одну сторону:

Все зависит от обстоятельств - и это действительно означает - начните с самого простого дизайна и рефакторизуйте его, когда увидите в этом необходимость. Возможно, это не будет выглядеть очень блестяще ООП - но я бы начал с одного класса и свойства 'CanAddSugar' и 'SugarAmount' (позже вы могли бы обобщить его до предиката CanAddIngredient(IngredientName), чтобы люди могли добавлять виски в свои напитки :)

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