Как инициализировать класс?
Я предполагаю следствие этого вопроса - когда полиморфизм можно считать отличным от ориентации объекта?
Полиморфизм не имеет абсолютно никакого отношения к объектной ориентации. Это просто означает, что одна и та же операция может вести себя по-разному в зависимости от типа (типов) ее операндов.
Функциональные языки, такие как ML или Haskell, имеют полиморфизм более 30 лет, и кто-то, кто лучше знает историю PL, может указать на некоторые примеры до 1962 года (то есть до OO).
Кристофер Стрейчи описал различие между параметрическим полиморфизмом и специальным полиморфизмом в 1967 году, поэтому полиморфизм, должно быть, уже существовал тогда. Поскольку полиморфизм был введен только в ОО в Simula-67, я предполагаю, что полиморфизм должен существовать до того, как он был введен в ОО.
8 ответов
шаблон 2) является шаблоном фабрики (метода) и напоминает мне синглтоны (static = singleton). Примечание синглтоны - зло . Заводской метод не является полиморфом. Вы не можете изменить его для тестов (т.е. вы не можете его издеваться). Это зло! Избегайте этого!
шаблон 3) нарушает то, что конструктор не должен делать слишком много. На мой взгляд, запрос к базе данных - это слишком много для специалиста. Объект и его создание - разные задачи, и их следует разделять. Более того, создание экземпляра должно быть отделено от экземпляра, поэтому попробуйте использовать фабрики (или инжекторы). Вы можете заменить фабрику проще, чем «новый класс», распространяемый через ваш код.
шаблон 1) остается, который является абстрактным шаблоном фабрики. Это хорошо. Вы можете использовать другую реализацию для тестирования (макет). Он отделяет творение от объекта. (Принцип единственной ответственности, как его называет Карл Бергквист.)
Итак, я бы выбрал образец 1.
Вы упускаете важную деталь. В частности, где вы берете строку подключения для разговора с базой данных?
Обновите каждый из ваших примеров, указав, откуда берется строка подключения, и я думаю, что это приведет к появлению правильного ответа.
Шаблон 1:
- Легче проверить
- Принцип единственной ответственности
- Может потребоваться больше кода.
Шаблон 2:
- Статические классы / методы могут значительно усложнить издевательство. Я стараюсь избегать этого, насколько могу.
Образец 3:
- Подходит для небольших классов. Но держите логику подальше от конструктора
. Но я думаю, что Orm и сериализация охватывают большинство частей (создание объекта).
Лично мне нравится, когда мои объекты абстрагируются от их источников данных, поэтому я бы выбрал такой метод, как №1. # 3 вы определенно не хотите делать ... слишком много обработки в конструкторах может привести к неприятностям. Предпочтение №1 по сравнению с №2, вероятно, будет зависеть от того, насколько «загруженными» вы хотите, чтобы ваши объекты данных были.
Если вы когда-нибудь предвидите получение объекта из другого источника данных, вы захотите придерживаться №1, поскольку это дает гораздо лучшую гибкость.
Я бы выбрал шаблон 1. Он представляет собой четкое разделение проблем между моделью предметной области и доступом к данным. Также проще провести модульное тестирование.
, если вы хотите, чтобы он инициализировался автоматически, используйте статический конструктор, который был вызван службой загрузчика классов .net.
, вы должны отделить класс объекта (акции) и логику, которая его заполняет (stockservice), но вместо того, чтобы писать класс stockservice, просто используйте orm для сопоставления db с вашим классом сущности (stock).
нечто похожее на метод 1, где вы должны вызывать классы уровня БД, чтобы загрузить объект оттуда, хотя вы можете хотите использовать ORM, чтобы позаботиться обо всем доступе к данным за вас