Резюме для программиста
Например, читаю у человека (сама статья не важна, привожу лишь один пример оттуда)
public class Turns
{
public int CurrentTurn { get; private set; }
internal void NextTurn ()
{
CurrentTurn++;
}
}В чём смысл такой архитектуры перед банальным публичным сеттером свойства CurrentTurn? Как я обезопашу себя, что кто-то присвоит CurrentTurn не то значение? Я могу вызвать метод NextTurn много раз и присвоить CurrentTurn всякую белиберду - неправильное значение. Какое-то раздувание "архитектуры" ради архитектуры.
Другие говорят, что тут мол принцип ответственности - мол, добавлять единичку к ходу (CurrentTurn) может только класс Turns, поэтому у него есть специальный метод для этого, а просто так присваивать любые значения или уменьшать их нельзя. А увеличивать сколько угодно много раз можно? Если по логике метод NextTurn не может быть вызван несколько раз подряд без проверки условий, но данная архитектура мне его вызвать позволяет, то смысла в этом всём громадье кода почти нет. Т.е. если разработчик не знает, как правильно использовать класс Turns, то он и с такой архитектурой набедокурит. А если знает, то проще дать публичный доступ к сеттеру CurrentTurn.
По моему, если так охота трястись, чтобы CurrentTurn не изменялся как попало, то тут больше подойдёт банальный публичный сеттер и валидация внутри класса Turns для свойства CurrentTurn. В представленной архитектуре я не вижу никакой особой инкапсуляции и тем более какой-то особой защиты от дурака по произвольному изменению свойства CurrentTurn.
Чел просто набросал гору кода, которая ничего не гарантирует, зато внешне по методичкам написана. Я такого кода полно встречал в разных примерах в интернете. Люди городят всякие инкапсуляции ради инкапсуляций, закрывают всё подряд, потом делают кучу методов, которые тупо дают доступ вместо закрытых свойств. Якобы они ограничивают тип доступа - типа только инкремент на 1, или только умножение. Но то, что я и с этими ограничениями могу натворить дел - это игнорируется. В результате есть раздутый класс строк на 100, который, если просто сделать полностью публичные свойства, ужмётся до максимум 10 строк. Народ за деревьями леса не видит.
Чем моя последняя работа была похожа на то, что я выше описывал - игровой проект и некий класс, к которому должны иметь доступ множество других классов, компонентов и т.д. - было клиент-серверное (или лучше сказать многокомпонентное) взаимодействие с очень частыми (буквально в реальном времени) изменениями состояния одного из компонентов в зависимости от пришедших с другого компонента данных. Одним компонентом была плата сбора данных, другим - десктопное приложение. Нужно было показывать анимированный график, отображающий ход процесса и расчёта. Там я тоже применил некий объект, в котором весь расчёт и происходил, и который хранил своё состояние. И также шарил этот объект среди десятков классов той же вью модели, чтобы она могла вытащить оттуда результаты и привязать их к контролам представления (включая графики). Только делалось всё это несколько раз в секунду.
Так и хочется спросить какую букву в ООП открытое поле нарушает... Я так понимаю вас инкапсуляция интересует, да? Если "скрывать" нечего, то можно доступ за методами и не прятать. Если последнюю наносекунду сэкономить надо. Пока всё в одном потоке проблем не будет. Лично я всё равно спрятал бы за get/set, не RTS же разрабатываем.
Это должно быть в
-----
А почитать что из себя представляет паттерн Singleton как-то вне возможностей?
То, что ты описываешь паттерну не соответствует.
А с методами легче?
-----
Как раз тот момент, когда знание того что есть сеттер и геттер может позволить не говорить глупости.
Как я обезопашу себя, что кто-то присвоит CurrentTurn не то значение?
-----
Действительно - Как?
Я вот хочу кусочек теста в котором это будет сделано...
Я имел ввиду, что по приведённому фрагменту класса непонятно зачем нужна такая инкапсуляция с прятанием сеттера - она ничего особо не обеспечивает. Может, чел упрощал, чтобы концепт рассказать, а в реале код обвешан ещё двумя десятками проверок условий и ещё столько же тестов. Всё может.
Не, он еще книгу не дописал. Но как то и так пока хватает, он на всех конференциях. И Microfrontend фрейморк вроде написал.
Как лучше сделать - тупо дать публичный доступ к изменению свойств (сеттерам), или городить методы типа SetProperty1, SetProperty2 и т.п.? Видел какие-то непонятные подходы, где сеттеры непубличны, геттеры публичны, зато публичны методы изменения свойств. В чём смысл, если так и так свойство можно поменять извне, но только через метод, а не свойство?
это явистов пустили в c#, они по старой памяти геттеры с сеттерами везде пихают))