#java #android #encapsulation
#java #Android #инкапсуляция
Вопрос:
При изучении BitmapFactory.Options класса Android я заметил, что его поля общедоступны для доступа и изменения.
Это противоречит общему правилу инкапсуляции, которое гласит, что поля должны быть объявлены private , а доступ / изменение к ним должно осуществляться с помощью public методов получения / установки. Таким образом, мы можем контролировать, как клиенты могут обращаться к полям нашего класса.
Это заставляет меня задуматься, не неправильно ли я понимаю концепцию инкапсуляции. При написании моих собственных классов, в каких ситуациях мне разрешено игнорировать инкапсуляцию, точно так же, как она игнорируется в BitmapFactory.Options ?
Можно утверждать, что инкапсуляция не нужна, когда нет необходимости в ограничениях при получении / установке значений полей. Но я думаю, что это не так с BitmapFactory.Options , потому что, например, BitmapFactory.Options.inSampleSize должно быть степенью 2:
декодер использует конечное значение, основанное на степенях 2, любое другое значение будет округлено в меньшую сторону до ближайшей степени 2.
Следовательно, разработчики могли бы объявить метод установки, который
- отклоняет значения, которые не являются степенью 2; или
- округляет заданное значение до ближайшей степени 2, прежде чем оно будет передано декодеру.
Ответ №1:
Для Javadoc указано inSampleSize , что
Кроме того, степени 2 часто быстрее / проще для декодера соблюдать.
Это означает, что class автор делегирует вам решение о том, какое значение присвоить ему.
Нигде не указано, что другие значения не будут работать, просто они не будут такими эффективными из-за фазы округления. Могут быть случаи использования, когда необходимо присваивать числа, не относящиеся к степени двойки.
Взглянув на это внутреннее static class , я не вижу причин использовать инкапсуляцию getters / setters.
Они были бы ненужными и избыточными, как и многие классы, которые «уважают» стиль JavaBean.
Зачем иметь 500 NLOC классов, когда можно иметь 50 NLOC ? Сохраняйте простоту.
Комментарии:
1. Я думаю, что другие значения работают, потому что в конечном итоге «декодер» округляет их до степени 2. Мой вопрос в том, почему бы не сделать это с помощью метода setter? Что касается инструкции «внутренний статический класс», не могли бы вы подробнее рассказать о том, почему такому классу не требуются геттеры / сеттеры? Хотя он статичен, его экземпляр все равно может быть создан через его общедоступный конструктор и иметь нестатические поля.
2. @SoSa забудьте о внутренней статической вещи, я просто указывал, как она объявлена. Класс decoder является подходящим местом для реализации логики округления, поскольку здесь она централизована. Если логика была внутри установщика, возможно, потребовалось бы дублировать ее внутри каждого класса, который используется декодером
3. Из вашего ответа я делаю вывод, что он не использует геттеры / установщики, потому что при доступе / изменении полей не требуется никаких ограничений? И в моих собственных классах я должен использовать методы получения / установки только тогда, когда мне нужно реализовать ограничение для клиентов класса на доступ / изменение полей?
4. @SoSa класс Options — это просто pojo, носитель информации. Будучи простым носителем, внутри него вообще не должно быть логики. Если ваш класс представляет собой простой pojo, который используется для переноса информации, вам обычно не нужно реализовывать проверки или какой-либо другой логический тип.