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

Question

Есть ли общие, в API дизайн, чтобы сделать что-то вроде этого:

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

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

Благодаря

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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