2012-05-01 2 views
2

Итак, я сдал экзамен сегодня в своем вступительном слове к курсу компьютерной науки. Один из вопросов касался шаблона дизайна Decorator, и это вызвало у меня некоторые проблемы. Мой вопрос заключается не в правильном ответе, а в том, действительно ли это хороший пример использования шаблона декоратора. Зачем украшать иерархию людей, когда это будет так же просто, и потребует меньше классов, чтобы класс населения рассчитал личностный ИМТ? Может ли декоратор действительно добавить функциональность в этом случае, поскольку BMI является производным свойством состояния объектов Person?Является ли это хорошим примером для шаблона проектирования Decorator?

Вопрос:

interface Person(){ 
    double getWeightInKG(); 
    double getHeightInMeters(); 
} 

Учитывая человек интерфейс выше использования шаблона декоратора для реализации класса рассчитанному ниже. ИМТ рассчитывается по формуле BMI = вес (кг)/высота (метры)^2. Для этого вам, возможно, придется разрабатывать и реализовывать другие классы и интерфейсы. Предположим, вы используете java.util.ArrayList.

+ Population: 
    - public void addPerson(Person p); 
    - public void removePerson(Person p); 
    - public double getAverageBMI(); 
    - public Person[ ] getPeopleInBMIRange(double bmi_min, bmi_max); 
    - public int populationSize(); 
+1

Потому что «население» представляет собой коллекцию людей. Это не калькулятор ИМТ, и не должно быть. Я немного склонен к тому, что для большинства населения характерна функциональность, характерная для ИМТ, - скорее похоже на информацию, которую вы фильтруете * из * населения. –

+0

@Dave, полностью согласен с тем, что функциональность BMI не должна быть в классе населения. –

+0

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

ответ

1

Я бы не использовал узор декоратора, чтобы украсить человека. Я хотел бы создать отдельный класс для расчета индекса массы тела, который выглядит примерно так:

class BMICalculator { 
    double getBMI(Person person) {} 
} 

Тогда я использовал бы BMICalculator в классе населения

class Population { 
    private final BMICalculator calc; 
    public double getAverageBMI() { 
     double total = 0; 
     for (Person p : people) { 
      total += calc.getBMI(p); 
     } 
     return total/people.size(); 
    } 
} 

Я не думаю, что декоратор подходит здесь.

+0

Значит, это будет называться «Стратегия». –

+0

Не совсем шаблон стратегии здесь. Это просто объектно-ориентированное программирование, используя другой объект для выполнения работы, которую он предназначен. –

+0

Если это не стратегия, то для этого еще раз мало оправдания, чтобы даже быть объектом. Почему не простой статический метод в этом случае? Точка наличия объекта - это динамическая отправка, в этом случае для обеспечения подключаемых различных реализаций. –

0

Идея состоит в том, чтобы определить интерфейс, например. BmiPerson extends Person { double bmi(); }, а затем агрегировать их в Population. Поэтому, хотя BmiPerson расширяет Person, он все еще может быть реализован так, чтобы содержать еще один Person внутри него - декоратор. По крайней мере, это лучшее, что я могу сделать. Это все еще не имеет большого смысла, поскольку Population принимает Person и не знает о дополнительном методе в BmiPerson.

+0

Не кажется ли глупо определять BmiPerson? –

+0

Да, это так :) Я обновил ответ, когда написал комментарий. –

+1

Но класс «Population» мог бы только собирать «BmiPerson's», предполагая, что методы BMI «Population» необходимы для доступа к этой информации. –

0

Этот вопрос является мусором, для (как минимум) 2 причин.

1. Вы не можете применить шаблон Decorator к интерфейсу. Цель шаблона - закрепить новое поведение на некоторой базе . Интерфейсы не имеют базовой функциональности.

2. Другая точка шаблона заключается в том, что вы можете применить новую функциональность на основе объекта за объектом. У вас никогда не было бы Person, BMI которого вы не захотите рассчитать.

Смежные вопросы