Резюме для программиста
Например, читаю у человека (сама статья не важна, привожу лишь один пример оттуда)
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 строк. Народ за деревьями леса не видит.
В Юнити, кстати, чтобы привязать данное из объекта к, например, графическому компоненту, нужно это данное сделать в виде публичного поля. Не свойства. Что, принципы ООП летят к чертям?
Для общего развития: а какую букву в SOLID нарушает "публичное поле"?
Чем моя последняя работа была похожа на то, что я выше описывал - игровой проект и некий класс, к которому должны иметь доступ множество других классов, компонентов и т.д. - было клиент-серверное (или лучше сказать многокомпонентное) взаимодействие с очень частыми (буквально в реальном времени) изменениями состояния одного из компонентов в зависимости от пришедших с другого компонента данных. Одним компонентом была плата сбора данных, другим - десктопное приложение. Нужно было показывать анимированный график, отображающий ход процесса и расчёта. Там я тоже применил некий объект, в котором весь расчёт и происходил, и который хранил своё состояние. И также шарил этот объект среди десятков классов той же вью модели, чтобы она могла вытащить оттуда результаты и привязать их к контролам представления (включая графики). Только делалось всё это несколько раз в секунду.
Так и хочется спросить какую букву в ООП открытое поле нарушает... Я так понимаю вас инкапсуляция интересует, да? Если "скрывать" нечего, то можно доступ за методами и не прятать. Если последнюю наносекунду сэкономить надо. Пока всё в одном потоке проблем не будет. Лично я всё равно спрятал бы за get/set, не RTS же разрабатываем.
Это должно быть в
-----
А почитать что из себя представляет паттерн Singleton как-то вне возможностей?
То, что ты описываешь паттерну не соответствует.
А с методами легче?
-----
Как раз тот момент, когда знание того что есть сеттер и геттер может позволить не говорить глупости.
Как я обезопашу себя, что кто-то присвоит CurrentTurn не то значение?
-----
Действительно - Как?
Я вот хочу кусочек теста в котором это будет сделано... 
Как я обезопашу себя, что кто-то присвоит CurrentTurn не то значение?
-----
Действительно - Как?
Я вот хочу кусочек теста в котором это будет сделано...
Я имел ввиду, что по приведённому фрагменту класса непонятно зачем нужна такая инкапсуляция с прятанием сеттера - она ничего особо не обеспечивает. Может, чел упрощал, чтобы концепт рассказать, а в реале код обвешан ещё двумя десятками проверок условий и ещё столько же тестов. Всё может.
Глянул sql.ru - в дотнетовском разделе ни одной длинной темы, чтобы страниц на 10 минимум. Все старые старпёры сидят, как и 5-10 лет назад, а срачей споров нет.
по приведённому фрагменту класса непонятно
-----
Как же ты будешь работать с чужим кодом... и кто после тебя сможет что-то поправить... 
А что профилировщики показывают?
Будет время, выложу примерчик, поиграетесь с профайлером для веб ассембли. 
Я так толком Блейзор и не пощупал.
Не нужно всё обобщать, речь идёт только о клиентской части + PWA.
А Florian Rappl не канает?
Мне имена не помогают. Мне б Дийкстру, Кнута или Мартина не забыть - уже радость :) Как называется?
Не, он еще книгу не дописал. Но как то и так пока хватает, он на всех конференциях. И Microfrontend фрейморк вроде написал.
Как лучше сделать - тупо дать публичный доступ к изменению свойств (сеттерам), или городить методы типа SetProperty1, SetProperty2 и т.п.? Видел какие-то непонятные подходы, где сеттеры непубличны, геттеры публичны, зато публичны методы изменения свойств. В чём смысл, если так и так свойство можно поменять извне, но только через метод, а не свойство?
это явистов пустили в c#, они по старой памяти геттеры с сеттерами везде пихают))
public static Singleton Instance { get { return instance; } }
Это должно быть в некоем статическом классе типа MySingletonServices?
Это должно быть в самом классе Singleton, чувак)))