Является ли нормальной практикой наличие геттеров, которые вызывают частные методы в дизайне API?

Распространено ли в API Design что-то вроде этого:

public ReadOnlyCollection GetCollection
{
get { // Get's read only collection here... 
}
}

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

Спасибо


person GurdeepS    schedule 29.09.2010    source источник
comment
Это Java или C#? Это не похоже на Java для меня...   -  person Jon Skeet    schedule 29.09.2010


Ответы (3)


Избегайте static - это особенность процедурного программирования. Используйте его только для служебных методов и общедоступных констант.

И нет - static != immutable, у них нет ничего общего. Статическое состояние — это глобальное состояние, которое не является потокобезопасным, и в вашем приложении не может быть более одного экземпляра статических данных.

Неизменяемость означает, что экземпляр объекта не может изменить свое внутреннее состояние. Это, например, String - как только вы его создадите, вы не сможете его изменить. Однако это не имеет ничего общего со статичностью.

Что касается первого вопроса - для геттера совершенно нормально выставлять внутреннюю коллекцию, особенно ее копию только для чтения.

person Bozho    schedule 29.09.2010
comment
Вы, вероятно, захотите убедиться, что объекты, составляющие коллекцию, также неизменны. - person Greg Case; 29.09.2010
comment
Я продолжаю задаваться вопросом, какой смысл иметь объект-экземпляр, если коллекцию все равно нельзя изменить. Я могу захотеть иметь частный конструктор и метод Get(), как фабрику? - person GurdeepS; 29.09.2010

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

person hvgotcodes    schedule 29.09.2010

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

Выбор статического или нестатического объекта зависит не столько от сохранения состояния или изменчивости. Во всяком случае, вы хотите спросить, должен ли класс представлять синглтон. Если он содержит «сведения о компании» в виде набора констант, то static будет уместным. Если класс в основном представляет собой DAO и повторно извлекает последние изменения в сведениях о компании по каждому запросу, вам может понадобиться нестатический класс. Похоже, ваш пример больше склоняется к первому.

person Steve Perkins    schedule 29.09.2010
comment
Если подумать, мой класс будет в значительной степени одноэлементным. Это небольшое приложение, и я хочу, чтобы использовалась одна общая коллекция. Это не похоже на Person, где каждый человек уникален. Это просто кажется неправильным? - person GurdeepS; 29.09.2010
comment
Использование шаблона singleton в значительной степени требует, чтобы класс (или, по крайней мере, метод доступа) был статическим. Тем не менее, вы, вероятно, слишком много внимания уделяете правильным или неправильным поступкам. Большая часть дизайна программного обеспечения субъективна, а не является вопросом черного или белого. Похоже, вы находитесь в серой зоне, где вы можете пойти любым путем и при этом оставаться респектабельным. Так что просто выберите один, поэкспериментируйте с ним некоторое время и рефакторинг в будущем, если вы решите, что вам нужно было пойти другим путем. - person Steve Perkins; 30.09.2010