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

Question

В API Design принято делать что-то вроде этого:

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

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

Спасибо

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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