Мотивирующие факторы для составления конкретного объекта? - PullRequest
Новая
       16

Мотивирующие факторы для составления конкретного объекта?

1 голос
/ 30 августа 2009

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

У меня есть пара руководящих принципов для этого:

  • Если это моделирует отношения в физическом мире.
  • Если у композитора есть данные, необходимые для создания объекта.
  • Если составной объект будет слушать композитора.

Что вы ищете, когда принимаете это решение?

Ответы [ 3 ]

3 голосов
/ 30 августа 2009

Ну, одна очень простая концепция, которая помогла мне в этом, - это просто концепция "имеет" против "есть". Спросите себя, является ли содержащийся объект чем-то, что содержит содержащийся объект, или это что-то, что содержит содержащийся объект? Если это что-то, что имеет содержащийся объект, тогда уместно удержание. В противном случае, возможно, вам стоит обратить внимание на наследство.

Собака - это животное, и у нее есть нос, поэтому это: 

class Animal
{
}

class Dog : Animal
{
    Nose n;
}

Теперь это работает нормально. Одна «проблема» в этом подходе заключается в том, что вы тесно связываете носы и собаки, поэтому иногда вы увидите такие вещи, как указатель на интерфейс, а не объект, или вы можете использовать Google «Dependency Injection». Но, как говорится, «имеет» и «есть» часто достаточно близко для работы правительства.

Вначале просто попробуйте множество примеров, и со временем это станет естественным. Если у вас получатся спагетти, бросьте в них несколько фрикадельок и попробуйте снова! :)

0 голосов
/ 01 сентября 2009

Иногда я оказываюсь с объект, который кажется удивительным, и тогда я добраться до точки, где я понимаю, «Хорошо, теперь я должен поставить это где-нибудь? "

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

0 голосов
/ 31 августа 2009

Какие альтернативы вы рассматриваете? Вы говорите о содержании против наследования, в комментариях Джона Локвуда о hasA и isA помощь в этом вопросе.

Или вы, возможно, говорите о «Контроле против Ассоциации»? Есть различные ароматы hasA. Например, Лицо может иметь Супруга, но явно не содержит Супруга. Существует разница между сменой супруга и сменой носа.

Виды отношений, которые вы считаете:

  • Время жизни: имеет ли смысл создавать Человека без Носа? Могут ли носы существовать без человека? Может ли человек существовать без супруга? Ответы на эти вопросы определяют тип выбранной вами операции над человеком. Вероятно, не нужен метод setNose (), хотя, возможно, нам нужен метод wipeNose (), и нам, вероятно, нужен метод marry (Person).

  • Кардинальность: сколько носов у человека? Сколько колес и мест у автомобиля? Ответы на это определяют виды структур данных? Просто ссылка? Список? Хеш-таблица?

Мне показалось полезным прочитать о UML-моделировании, особенно диаграммах классов. Это отражает большой опыт того, как с пользой фиксировать различные виды отношений.

...