0 added
0 removed
Original
2026-01-01
Modified
2026-02-26
1
<p>Сеттеры (setters) служат для изменения внутреннего состояния объекта. Как и геттеры, они именуются особым образом. К сеттерам обычно добавляется префикс<em>set</em>, если этот сеттер что-то устанавливает и<em>add</em>- если добавляет.</p>
1
<p>Сеттеры (setters) служат для изменения внутреннего состояния объекта. Как и геттеры, они именуются особым образом. К сеттерам обычно добавляется префикс<em>set</em>, если этот сеттер что-то устанавливает и<em>add</em>- если добавляет.</p>
2
<p>На практике изменения объектов происходят почти всегда с помощью сеттеров, и крайне редко - через изменение свойства напрямую. Причём объекты (впрочем, как и любая абстракция) иногда хранят внутри себя свойства, которые нельзя изменять снаружи (например, соединение с базой данных), и для них не делают сеттеров.</p>
2
<p>На практике изменения объектов происходят почти всегда с помощью сеттеров, и крайне редко - через изменение свойства напрямую. Причём объекты (впрочем, как и любая абстракция) иногда хранят внутри себя свойства, которые нельзя изменять снаружи (например, соединение с базой данных), и для них не делают сеттеров.</p>
3
<p>Вообще говоря, с сеттерами связано много головной боли. Несмотря на сокрытие данных, встроенное в объекты, можно легко создать ситуацию, в которой из одного объекта извлекается другой объект и меняется. Естественно, исходный объект об этих изменениях ничего не знает. Проблема обостряется тогда, когда один объект используется по всему приложению. В такой ситуации он ведёт себя как глобальная переменная (в худшем её проявлении). Изменения, сделанные в одном месте, коснутся всего.</p>
3
<p>Вообще говоря, с сеттерами связано много головной боли. Несмотря на сокрытие данных, встроенное в объекты, можно легко создать ситуацию, в которой из одного объекта извлекается другой объект и меняется. Естественно, исходный объект об этих изменениях ничего не знает. Проблема обостряется тогда, когда один объект используется по всему приложению. В такой ситуации он ведёт себя как глобальная переменная (в худшем её проявлении). Изменения, сделанные в одном месте, коснутся всего.</p>
4
<p>Например, ранее мы создали класс для работы с рациональными числами. Если бы методы add() и sub() изменяли объект, на котором вызываются, то получить неверные расчёты стало бы крайне просто. Достаточно использовать одно рациональное число в нескольких местах, и любое его изменение повлияет на всех, кто использует это число. Абсолютно такая же ситуация и с графическими примитивами на плоскости.</p>
4
<p>Например, ранее мы создали класс для работы с рациональными числами. Если бы методы add() и sub() изменяли объект, на котором вызываются, то получить неверные расчёты стало бы крайне просто. Достаточно использовать одно рациональное число в нескольких местах, и любое его изменение повлияет на всех, кто использует это число. Абсолютно такая же ситуация и с графическими примитивами на плоскости.</p>
5
<p>Если внутри moveUp() происходит изменение точек (вместо создания новых), то такое изменение повлияет и на segment2, хотя мы и не собирались его перемещать.</p>
5
<p>Если внутри moveUp() происходит изменение точек (вместо создания новых), то такое изменение повлияет и на segment2, хотя мы и не собирались его перемещать.</p>
6
<p>Существует ли способ сделать всё красиво? Нет, фундаментальная проблема "изменяемое состояние" может быть убрана только отказом от изменения и созданием нового на основе старого. Последний приём подходит не всегда, но мы уже использовали его на практике, например, в рациональных числах.</p>
6
<p>Существует ли способ сделать всё красиво? Нет, фундаментальная проблема "изменяемое состояние" может быть убрана только отказом от изменения и созданием нового на основе старого. Последний приём подходит не всегда, но мы уже использовали его на практике, например, в рациональных числах.</p>