Изменение публичных членов класса

Допустим, есть у меня класс

    public sealed class TwitchVod
    {
        public string Title { get; set; }
        public string VideoId { get; set; }
        public string StreamId { get; set; }
        public string VideoUrl { get; set; }
	}

Потом я, обычно, где-нибудь, допустим в классе формы, делаю метод

	private void ParseVod(JObject json)
	{
		TwitchVod vod = new TwitchVod();
		vod.Title = json.Value<...>...
                //и т.д.
	}

То есть, заполняю публичные члены класса (которые, по-идее, не должны меняться) извне. Но ведь это же плохо так делать? :man_shrugging: А как в таких случаях делают, кроме как авто-десериализацией?
Единственная идея - перенести метод парсинга в сам класс и сделать private set :thinking:

Смотря чем плохо :man_shrugging:
Конструктор можно использовать, чтоб гарантировать, что недоинициализированный объект не может существовать, и чтоб можно было сделать неизменяемым после создания.

Если недобросовестно использовать класс, то можно изменять значения в любой момент. Этим и плохо.

Я знаю. Но тогда в конструктор придётся передавать несколько десятков аргументов. Это тоже такой себе вариант :man_shrugging:

Можно паттерн Билдер/Fluent Builder, типа

TwitchVod vod = builder
    .setTitle("")
    .setId(42)
    .build();

Паттерн проектирования Builder (Строитель) в Java / Habr

Это значит, всё-равно нужны публичные сеттеры?

Не, билдер тоже вызывает конструктор в конце, просто изолировано в одном месте.

Ну если надо запретить редактирование только извне то пометить все свойства как private set
А еще можно сделать их readonly тогда изменить их можно будет только в конструкторе один раз.

Ну так напишите мануал по классу. В любом случае люди будут его использовать именно что недобросовестно, но надо им написать какие при этом будут результаты.

А запечатывать все классы это тоже так себе… была такая либа ScottPlot так на первых версиях половина классов была запечатана и их невозможно было переопределить. И добавить какую либо реализацию метода было просто катастрофой. И как результат пришлось делать копию компонента из исходников … Поэтому класс должен быть максимально гибким для переиспользования в будущем.

Зачем повторять то что я уже написал? :slightly_smiling_face: Передавать в конструктор около 30 параметров как-то уж совсем не очень.

На счёт запечатывания это ещё не окончательное решение. Пусть пока так будет.

Тогда откуда взялись setTitle и setId? :thinking: Они приватные чтоли? :thinking:

Так посмотрите статью. Билдер это другой объект, в конце создает нужный объект например через конструктор.

Чёт я опять не улавливаю связи с темой :thinking: Там они создали кучу вспомогательных классов и всё-равно в результате всё в конструктор передаётся, только кода больше :man_shrugging: Не вижу упрощения.

можно один, TwitchVodBuilder.

Да, но только в одном месте.

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

Ну так и без этого конструктор ведь один :thinking: Просто параметров для передачи много и с билдером их меньше не станет :man_shrugging:

Не вижу отличий от передачи того же в конструктор :man_shrugging: Не пойму, что именно упрощает билдер.

Не, в смысле что если в разных местах кода надо создавать такие объекты, то не надо везде трогать конструктор напрямую.

А, дошло. Но мне в разных местах не надо (хотя теперь суть идеи понял).
Я имею ввиду, что

MyClass my = new MyClass();
my.Parse(json);

так не было бы проще? :man_shrugging: Ну и запретить повторный парсинг.

Можно и так. :man_shrugging:
Но обычно считается хорошей идеей не смешивать всё в кучу. Вдруг понадобится парсить из разных видов джсонов и т.п., или передавать какие-то еще данные/парсеры.

Для библиотек идея запечатывания может быть в том, чтобы гарантировать, что никто не зависит от внутренних деталей реализации, и можно менять их в следующих версиях не ломая чужой код.

Но да, наверно лучше просто документировать, что совместимость не гарантируется. Есть же популярные языки вообще без ограничений доступа, и всё ок )