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 set
Смотря чем плохо
Конструктор можно использовать, чтоб гарантировать, что недоинициализированный объект не может существовать, и чтоб можно было сделать неизменяемым после создания.
Ну если надо запретить редактирование только извне то пометить все свойства как private set
А еще можно сделать их readonly тогда изменить их можно будет только в конструкторе один раз.
Ну так напишите мануал по классу. В любом случае люди будут его использовать именно что недобросовестно, но надо им написать какие при этом будут результаты.
А запечатывать все классы это тоже так себе… была такая либа ScottPlot так на первых версиях половина классов была запечатана и их невозможно было переопределить. И добавить какую либо реализацию метода было просто катастрофой. И как результат пришлось делать копию компонента из исходников … Поэтому класс должен быть максимально гибким для переиспользования в будущем.
Чёт я опять не улавливаю связи с темой Там они создали кучу вспомогательных классов и всё-равно в результате всё в конструктор передаётся, только кода больше Не вижу упрощения.
Ну и можо например не один метод в билдере на каждое свойство, а как-нибудь по-другому, в одном методе сразу несколько значений запоминать и т.д.
Еще можно в одном месте кода установить только часть свойств и передать куда-то билдер для завершения оставшейся части.
Можно и так.
Но обычно считается хорошей идеей не смешивать всё в кучу. Вдруг понадобится парсить из разных видов джсонов и т.п., или передавать какие-то еще данные/парсеры.
Для библиотек идея запечатывания может быть в том, чтобы гарантировать, что никто не зависит от внутренних деталей реализации, и можно менять их в следующих версиях не ломая чужой код.
Но да, наверно лучше просто документировать, что совместимость не гарантируется. Есть же популярные языки вообще без ограничений доступа, и всё ок )