Сообщение Re[2]: Конструктор с параметрами vs метод Init -- стоит ли и от 31.03.2016 13:25
Изменено 31.03.2016 13:25 Shmj
Здравствуйте, _NN_, Вы писали:
_NN>Нет конечно
_NN>Обычно метод Init не нужен, потому как возникают сразу множество проблем контролирования состояния.
А как насчет контрактов (interface). Как там описать конструктор?
_NN>Что если два раза кто-нибудь вызовет ? Из двух потоков ? И т.п.
По поводу двух раз -- уже написал, достаточно 1 поля.
По поводу потоков. Инстанс класса считается не потокобезопасным, если не указано иное. Если хотите сделать потокобезопасным -- то вам нужно озаботиться не только этим методом, но и всеми другими.
_NN>С обобщениями действительно проблема и есть предложение, однако не так часто нужно и всегда есть обходные пути.
_NN>Насчёт сериализации, то для объектов-данных (data object) вообще не нужен конструктор и логика.
А проверка того что все обязательные поля установлены?
_NN>Есть предложение о добавления конструктора и расширения класса методами, но это не повод создавать всегда двухуровневую иницализацию.
При использовании контрактов двухуровневой не избежать.
_NN>Нет конечно
_NN>Обычно метод Init не нужен, потому как возникают сразу множество проблем контролирования состояния.
А как насчет контрактов (interface). Как там описать конструктор?
_NN>Что если два раза кто-нибудь вызовет ? Из двух потоков ? И т.п.
По поводу двух раз -- уже написал, достаточно 1 поля.
По поводу потоков. Инстанс класса считается не потокобезопасным, если не указано иное. Если хотите сделать потокобезопасным -- то вам нужно озаботиться не только этим методом, но и всеми другими.
_NN>С обобщениями действительно проблема и есть предложение, однако не так часто нужно и всегда есть обходные пути.
_NN>Насчёт сериализации, то для объектов-данных (data object) вообще не нужен конструктор и логика.
А проверка того что все обязательные поля установлены?
_NN>Есть предложение о добавления конструктора и расширения класса методами, но это не повод создавать всегда двухуровневую иницализацию.
При использовании контрактов двухуровневой не избежать.
Re[2]: Конструктор с параметрами vs метод Init -- стоит ли и
Здравствуйте, _NN_, Вы писали:
_NN>Нет конечно
_NN>Обычно метод Init не нужен, потому как возникают сразу множество проблем контролирования состояния.
А как насчет контрактов (interface). Как там описать конструктор?
_NN>Что если два раза кто-нибудь вызовет ? Из двух потоков ? И т.п.
По поводу двух раз -- уже написал, достаточно 1 поля для проверки.
По поводу потоков. Инстанс класса считается не потокобезопасным, если не указано иное. Если хотите сделать потокобезопасным -- то вам нужно озаботиться не только этим методом, но и всеми другими.
_NN>С обобщениями действительно проблема и есть предложение, однако не так часто нужно и всегда есть обходные пути.
_NN>Насчёт сериализации, то для объектов-данных (data object) вообще не нужен конструктор и логика.
А проверка того что все обязательные поля установлены?
_NN>Есть предложение о добавления конструктора и расширения класса методами, но это не повод создавать всегда двухуровневую иницализацию.
При использовании контрактов двухуровневой не избежать.
_NN>Нет конечно
_NN>Обычно метод Init не нужен, потому как возникают сразу множество проблем контролирования состояния.
А как насчет контрактов (interface). Как там описать конструктор?
_NN>Что если два раза кто-нибудь вызовет ? Из двух потоков ? И т.п.
По поводу двух раз -- уже написал, достаточно 1 поля для проверки.
По поводу потоков. Инстанс класса считается не потокобезопасным, если не указано иное. Если хотите сделать потокобезопасным -- то вам нужно озаботиться не только этим методом, но и всеми другими.
_NN>С обобщениями действительно проблема и есть предложение, однако не так часто нужно и всегда есть обходные пути.
_NN>Насчёт сериализации, то для объектов-данных (data object) вообще не нужен конструктор и логика.
А проверка того что все обязательные поля установлены?
_NN>Есть предложение о добавления конструктора и расширения класса методами, но это не повод создавать всегда двухуровневую иницализацию.
При использовании контрактов двухуровневой не избежать.