То, что мы сначала рисуем доменную (концептуальную) модель, не значит, что мы не должны править эту модель после попытки нарисовать логическую структуру данных (нормализованную ER диаграмму).
Именно это и значит — не должны.
Если вынуждены «затачивать» доменную модель под физику — это не верно.
Это значит то, что доменная модель была не верна изначально!
До тех пор, пока не получена корректная (нормализованная) и достаточно полная схема БД — как можно говорить о корректной доменной модели?
Простите, но вы путаете причину со следствием.
В начале делается доменная модель, последнее — физическая модель, в конкретном случае «схема БД»
Domain model
A domain model is a system of abstractions that describes selected aspects of a sphere of knowledge, influence or activity (a domain[3]). The model can then be used to solve problems related to that domain. The domain model is a representation of meaningful real-world concepts pertinent to the domain that need to be modeled in software. The concepts include the data involved in the business and rules the business uses in relation to that data.
A domain model generally uses the vocabulary of the domain so that a representation of the model can be used to communicate with non-technical stakeholders.
Usage
A domain model is generally implemented as an object model within a layer that uses a lower-level layer for persistence and «publishes» an API to a higher-level layer to gain access to the data and behavior of the model.
In the Unified Modeling Language (UML), a class diagram is used to represent the domain model.
Logical data model or Logical schema
A logical data model or logical schema is a data model of a specific problem domain expressed independently of a particular database management product or storage technology (physical data model) but in terms of data structures such as relational tables and columns, object-oriented classes, or XML tags. This is as opposed to a conceptual data model, which describes the semantics of an organization without reference to technology.
Physical data model (or database design)
A physical data model (or database design) is a representation of a data design as implemented, or intended to be implemented, in a database management system. In the lifecycle of a project it typically derives from a logical data model, though it may be reverse-engineered from a given database implementation. A complete physical data model will include all the database artifacts required to create relationships between tables or to achieve performance goals, such as indexes, constraint definitions, linking tables, partitioned tables or clusters. Analysts can usually use a physical data model to calculate storage estimates; it may include specific storage allocation details for a given database system.
И дальше пишем код и параллельно делаем логическую и физическую схему данных.
А вот это и есть проблема.
потому что получается «И тут натыкаемся на замечательную вещь. » — это значит что бизнес анализ не завершен, а архитектор не провел валидацию доменной модели/ SergeyUstinov «Это и есть концептуальная модель данных (по крайней мере с моей точки зрения). ».
Один из результатов работы архитектора — валидация целостности доменной модели, что он получил от бизнес аналитика. с точки зрения: кто делает, что делает, над чем делает и зачем делает. Роли/Системы, действия, данные и конечный результат.
То есть два куска очень тесно связанных данных оказались в разных модулях, что может доставить много «приятных» минут.
Задача архитектора грамотно «нарезать», что бы не было косяков после в разработке.
Схема БД (ERD) — это в первую очередь логическая структура данных, а не физическая. Вы её точно ни с чем не путаете?
Ключевые слова, на которые среагировал это «База данных» и ".А ERD БД — это вполне конкретная вещь, которую можно напрямую трансформировать в SQL код создания объектов БД"
Диаграмму надо рисовать в первую очередь для нормализации (денормализации), а типы данных для этой задачи не важны.
А без типов не сгенерить схему для БД и SQL для генерации. Да и нормальзация — это обычно термин из области БД.
вот и выходит что «физическая модель»
была бы приписка
Conceptual data model, Logical data model, Physical data model — не вопрос :)
Потому что ERD предметной области — это нечто достаточно эфемерное, что нельзя непосредственно воплотить в артефактах системы. А ERD БД — это вполне конкретная вещь, которую можно напрямую трансформировать в SQL код создания объектов БД, можно нормализовать и т.д. А как, например, нормализовать ERD предметной области? :)))
Вроде бы всегда разделяли логическую модель данных (количество в штуках или деньгах) и физическую модель данных (количество в long или double в поле count и amount).
Понятное дело, что как программист, вы можете сразу родить анемичную свернутую модель, «интуитивно», но постулировать такой путь как «best practice» сомнительно. И проектировать от «физики» точно не есть хорошо
Если проходит квалификационные признаки (запрет создания более одного экземпляр в рамках системы), как мы определились ранее, то да — можно рассматривать как вариант имплементации Singleton «мясом наружу», в котором границы системы «все, что снаружи класса», меняются на «все, что внутри контейнера».
Детали имплементации и защиты/запрета другие, результат тот же.
Критерии — удобство конфигурирования и использования полученных компонент.
Удобство меряется в деньгах, человеко-часах, строках кода и т.д. в чем-то с цифирками.
При появлении новых требований один подход требует рефакторинга (выпиливания синглтонов), а другой подход — не требует. Преимущества налицо.
Если вы предполагаете, что Singleton это обязательно XXX.GetInstance() внутри, предположим, класса DummyBusinessLogic, то да, это весьма и весьма спорная практика. Но какая религия запрещает XXX.GetInstance() передать снаружи класса ручками или используя контейнер?
Почему плохая практика применения инструмента, переносится и проекцируется на сам инструмент?
Все таки глобальные (не принадлежащие контексту исполнения, но доступные в нем) средства синхронизации оказались нужны.
В этом и проблема. Вы не хотите отделить «глобальные» от «доступные». Если средства синхронизации передать как зависимость, они останутся доступными, но пропадут проблемы, присущие глобальности.
С чего вы это взяли? Я вроде тоже самое и написал. Как хотите так и получайте их. Способ получения зависит от дизайна приложения. Другое дело, что безконтрольное создание их внутри контекста исполнения приводит к невозможности решения задачи, что приводит необходимости выносить создание таких объектов наружу, в более контролируемые и управляемые условия. Желательно не зависящие от человека и контролируемые инструментально.
Я кажется понял, что вы хотели сказать: вы не понимаете, как применить архитектурный паттерн IoC + DI в проекте на COM-ах.
Значит, этот подход не везде применим, и поэтому его значение переоценено.
Вот люблю «телепатов», только они почему-то всегда проецируются свои мысли и полагают, что другая сторона думает в точности так как и они сами. Вот с чего вы это взяли? Или логическая цепочка по принципу «Спичками интересуется, значит спичек нет! Спичек нет — значит не стоит?»
Когда ваял на COM тогда и понятия то такого не было IoC и DI. Это уже потом народ узнал, что передача интерфейсов в «другой интерфейс», а не дергать CoCreateInstance «по месту» это называется DI почитав умных книжек.
Но дискуссия то не об этом была.
Критерии оценки — метрики и методология оценки решения какие?
Метрики и метология сравнения решений?
Критерии оценки — метрики и методология оценки на принадлежность «шаблону»?
Эталон решения согласно «шаблону» какой?
Какой check-list на принадлежность «к эталону» и «шаблону»?
Я очень ценю исследование сферических коней в хрустальном замке, очень ценю идеальные решения, но еще больше меня интересует «ценник» на этих решения. Если где-то прибыло, значит где-то убыло. Не бывает чудес.
Я всегда стараюсь пообщаться с горячими стронниками какого-то решения и всегда стараюсь получить ответ на вопрос «А в каких случаях ваше Идеальное Решение не работает? Где границы применения вашего Идеального решения ?» Если сторонник не может внятно дать ответы на этот простой вопрос — значит не до конца понимает, что он «продает» и чем «пользуется», или понимает настолько, что не желает говорить о недостатках и старательно обходит эту тему.
Простой мысленный эксперимент сделать работу с шаренным ресурсом через множество инстансов в нескольких потоках/процессах без каких- либо средство координации и синхронизации оказался не удачным. Все таки глобальные (не принадлежащие контексту исполнения, но доступные в нем) средства синхронизации оказались нужны.
Вы получаете интерфейс, а количество экземпляров реализации определяется не вами а ее автором.
Ага… из астрала получаются интерфейсы:)
а количество экземпляров реализации определяется не вами а ее автором.
И где здесь противоречие?
Вообще-то посыл был к тому, что прямое использование «класс» не проходит, как и мплементация «в лоб».
В рамках одного языка, одного приложения — без проблем. Но как только что-то выходит за рамки «эталонной реализации» (осталось понять какая она «эталонная») — тут вылазит куча ограничений и нарушений, и наследуется не правильно, и интерфесы кривые, и хранится не там и не так инстанс, и вообще задача не правильная.
Ключевое условие — единственность экземпляра известного класса.
В результате наследования класс меняется.
Ага. Ну… допустим :)
Но тут возникает две другие проблемы :)
Есть такая штука, как взаимодействие систем, написанных на разных язык. В частности MS COM (ActiveX, Ole 1.x/2.x, COM+, DCOM). У нее вообще нет классов, как таковых, а просто куча интерфейсов и сервисная инфраструктура. Но при этом она прекрасно позволяет реализовать Singleton :)
JavaScript до последних спецификации не поддерживал классы, но имплементации были :)
JavaScript classes
JavaScript classes introduced in ECMAScript 2015 are primarily syntactical sugar over JavaScript's existing prototype-based inheritance
Очевидно, что шаблон проектирования не должен зависеть от конкретной имплементации и инфраструктуры. Наоборот — варианты имплементации должны реализовывать указанные требования (синтаксическими или ифраструктурными механизмами)
Не важно, как называется. Главное, что создаётся объект известного класса и объект другого класса быть получен не может.
Откуда такое ограничение? Вроде как на этот счет нету никаких запретов вроде «если используется наследование, то singleton превращается в тыкву и не важно или singleton наследуется от XXX или от singleton наследуется ZZZ».
Определись уже тогда: для Вас, все таки, критична конкретная имлементация, или нет? Если критична, то с какими оговорками?
Если нет и критерий конечный результат, то остается ключевой, на мой взгляд вопрос: границы «the system» в которых «один экземпляр».
Некорректная постановка вопроса. DummyBL ничего не знает про Logger.
Если будет вместо интерфейса абстрактный класс, о котором «будет знать», что-то принципиально поменяется?
Вызывая Logger::getInstance мы обязаны получить Logger, если следовать канонам Singleton.
Вроде как шаблон не требует наличия getInstance :)
Поясняющая реализция — предполагает его наличие. Кто-же спорит.
Тот же JavaScript «JavaScript does not have native support for private properties», но Singleton тоже имплементируют :)
Приложение не может создать ещё один VMM не потому, что он SIngleton, а потому что нет таких API (другими словами, приложение имеет доступ к интерфейсу, но не к реализации, поэтому при всём желании не может вызвать конструктор).
Внутри ядра ОС — пожалуйста, создавай сколько хочешь (если логика ОС подразумевает, например, отдельные виртуализированные машины).
Именно! Границы системы, внутри которых требуется один экземпляр и нельзя плодить новые! Детали имплементации — не важны и зависят от более детальных требований.
Типовое решение — архитектура. Нельзя писать код, не удовлетворяющий архитектуре проекта.
И тут есть пара подходов:
1) Компонент пишет в лог только через синглтон «Logger»
2) Компонент пишет в лог только через логгер, который передан ему как зависимость.
Оба подхода решают проблему с беспорядочным логгированием, но у второго подхода компоненты получаются более гибкими и готовыми к переиспользованию без доработок.
Вот мы почти пришли к общему знаменателю.
Арихитектурно, все-таки нужен какой-то «единый механизм» позволющий предотвращать коллизии при работе с общими ресурсами.
Теперь, давайте рассмотрим чуть детальнее «типовую имплементацию» Singleton class Logger
{
private static Logger _logger = new Logger();
private Logger() {}
public static Logger GetInstance()
{
return _logger;
}
}
Вопрос: а является ли это класс Singleton? Ответ: и нет и да :)
Почему нет? Очень просто — внутри то то можно насоздавать дофига экземпляров логера: class Logger
{
private static Logger _logger = new Logger();
.....
private static Logger _loggerN = new Logger();
private Logger() {}
public static Logger GetInstance()
{
return _logger;
}
}
Почему да? Так же просто — границы системы, где доступен один экземпляр, лежит снаружи этого класса.
Если наш Logger будет реализовывать какой-то интерфес — он перестанет быть Singleton в каких-то рамках? class Logger: ILogger
{
...
private Logger() {}
public static ILogger GetInstance() {...}
}
Очевидно что нет.
А что произойдет, если мы сделаем такую конструкцию? class DummyBL
{
private ILogger _logger;
public DummyBL(ILogger logger)
{
this._logger = logger;
}
}
ILogger loggerTempRef = Logger.GetInstance();
DummyBL bl1 = new DummyBL (loggerTempRef);
DummyBL blN = new DummyBL (loggerTempRef);
У нас появляется граница системы — инстанс класса DummyBL.
Вроде ничего не нарушено с точки зрения шаблона, только у нас решении появилось две границы системы: «снаружи» Logger и «вложенная» в нее граница DummyBL. Похоже на матрешку.
А что произойдет, если мы уберем одну границу, следующим образом?
class Logger: ILogger
{
... private public Logger() {}
}
ILogger loggerTempRef = new Logger(); // миграция метода GetInstance() из класса Logger
DummyBL bl1 = new DummyBL (loggerTempRef);
DummyBL blN = new DummyBL (loggerTempRef);
Для самого Logger — ничего не поменялось. Как внутри него можно было плодить экземпляры, так можно и продолждать.
Для самого DummyBL — тоже ничего не поменялось. Внутри него по прежнему нельзя создавать экземпляры Logger.
Остался ли для DummyBL Logger по прежнему Singleton или нет? С точки зрения результата — да.
Граница системы вместо «все, что снаружи Logger», сменилась на «все, что внутри DummyBL»
Фактически, вывернули Singleton «мясом наружу» в данном варианте имплементации, при этом все требования соблюдены: один экземпляр в рамках системы.
Дополнительно — использовали механизм DI, а не «Service Locator» встроенный в начальную имлементацию Singleton.
Именно это и значит — не должны.
Если вынуждены «затачивать» доменную модель под физику — это не верно.
Это значит то, что доменная модель была не верна изначально!
Простите, но вы путаете причину со следствием.
В начале делается доменная модель, последнее — физическая модель, в конкретном случае «схема БД»
A domain model generally uses the vocabulary of the domain so that a representation of the model can be used to communicate with non-technical stakeholders.
Usage
A domain model is generally implemented as an object model within a layer that uses a lower-level layer for persistence and «publishes» an API to a higher-level layer to gain access to the data and behavior of the model.
In the Unified Modeling Language (UML), a class diagram is used to represent the domain model.
А вот это и есть проблема.
потому что получается «И тут натыкаемся на замечательную вещь. » — это значит что бизнес анализ не завершен, а архитектор не провел валидацию доменной модели/ SergeyUstinov «Это и есть концептуальная модель данных (по крайней мере с моей точки зрения). ».
Один из результатов работы архитектора — валидация целостности доменной модели, что он получил от бизнес аналитика. с точки зрения: кто делает, что делает, над чем делает и зачем делает. Роли/Системы, действия, данные и конечный результат.
Задача архитектора грамотно «нарезать», что бы не было косяков после в разработке.
Ключевые слова, на которые среагировал это «База данных» и ".А ERD БД — это вполне конкретная вещь, которую можно напрямую трансформировать в SQL код создания объектов БД"
А без типов не сгенерить схему для БД и SQL для генерации. Да и нормальзация — это обычно термин из области БД.
вот и выходит что «физическая модель»
была бы приписка
Conceptual data model, Logical data model, Physical data model — не вопрос :)
Вроде бы всегда разделяли логическую модель данных (количество в штуках или деньгах) и физическую модель данных (количество в long или double в поле count и amount).
Понятное дело, что как программист, вы можете сразу родить анемичную свернутую модель, «интуитивно», но постулировать такой путь как «best practice» сомнительно. И проектировать от «физики» точно не есть хорошо
UDDI?
closed
Детали имплементации и защиты/запрета другие, результат тот же.
Удобство меряется в деньгах, человеко-часах, строках кода и т.д. в чем-то с цифирками.
Если вы предполагаете, что Singleton это обязательно XXX.GetInstance() внутри, предположим, класса DummyBusinessLogic, то да, это весьма и весьма спорная практика. Но какая религия запрещает XXX.GetInstance() передать снаружи класса ручками или используя контейнер?
Почему плохая практика применения инструмента, переносится и проекцируется на сам инструмент?
С чего вы это взяли? Я вроде тоже самое и написал. Как хотите так и получайте их. Способ получения зависит от дизайна приложения. Другое дело, что безконтрольное создание их внутри контекста исполнения приводит к невозможности решения задачи, что приводит необходимости выносить создание таких объектов наружу, в более контролируемые и управляемые условия. Желательно не зависящие от человека и контролируемые инструментально.
Вот люблю «телепатов», только они почему-то всегда проецируются свои мысли и полагают, что другая сторона думает в точности так как и они сами. Вот с чего вы это взяли? Или логическая цепочка по принципу «Спичками интересуется, значит спичек нет! Спичек нет — значит не стоит?»
Когда ваял на COM тогда и понятия то такого не было IoC и DI. Это уже потом народ узнал, что передача интерфейсов в «другой интерфейс», а не дергать CoCreateInstance «по месту» это называется DI почитав умных книжек.
Но дискуссия то не об этом была.
Критерии оценки — метрики и методология оценки решения какие?
Метрики и метология сравнения решений?
Критерии оценки — метрики и методология оценки на принадлежность «шаблону»?
Эталон решения согласно «шаблону» какой?
Какой check-list на принадлежность «к эталону» и «шаблону»?
Я очень ценю исследование сферических коней в хрустальном замке, очень ценю идеальные решения, но еще больше меня интересует «ценник» на этих решения. Если где-то прибыло, значит где-то убыло. Не бывает чудес.
Я всегда стараюсь пообщаться с горячими стронниками какого-то решения и всегда стараюсь получить ответ на вопрос «А в каких случаях ваше Идеальное Решение не работает? Где границы применения вашего Идеального решения ?» Если сторонник не может внятно дать ответы на этот простой вопрос — значит не до конца понимает, что он «продает» и чем «пользуется», или понимает настолько, что не желает говорить о недостатках и старательно обходит эту тему.
Простой мысленный эксперимент сделать работу с шаренным ресурсом через множество инстансов в нескольких потоках/процессах без каких- либо средство координации и синхронизации оказался не удачным. Все таки глобальные (не принадлежащие контексту исполнения, но доступные в нем) средства синхронизации оказались нужны.
Ага… из астрала получаются интерфейсы:)
И где здесь противоречие?
Вообще-то посыл был к тому, что прямое использование «класс» не проходит, как и мплементация «в лоб».
В рамках одного языка, одного приложения — без проблем. Но как только что-то выходит за рамки «эталонной реализации» (осталось понять какая она «эталонная») — тут вылазит куча ограничений и нарушений, и наследуется не правильно, и интерфесы кривые, и хранится не там и не так инстанс, и вообще задача не правильная.
Ага. Ну… допустим :)
Но тут возникает две другие проблемы :)
Очевидно, что шаблон проектирования не должен зависеть от конкретной имплементации и инфраструктуры. Наоборот — варианты имплементации должны реализовывать указанные требования (синтаксическими или ифраструктурными механизмами)
Откуда такое ограничение? Вроде как на этот счет нету никаких запретов вроде «если используется наследование, то singleton превращается в тыкву и не важно или singleton наследуется от XXX или от singleton наследуется ZZZ».
Определись уже тогда: для Вас, все таки, критична конкретная имлементация, или нет? Если критична, то с какими оговорками?
Если нет и критерий конечный результат, то остается ключевой, на мой взгляд вопрос: границы «the system» в которых «один экземпляр».
Если будет вместо интерфейса абстрактный класс, о котором «будет знать», что-то принципиально поменяется?
Вроде как шаблон не требует наличия getInstance :)
Поясняющая реализция — предполагает его наличие. Кто-же спорит.
Тот же JavaScript «JavaScript does not have native support for private properties», но Singleton тоже имплементируют :)
Именно! Границы системы, внутри которых требуется один экземпляр и нельзя плодить новые! Детали имплементации — не важны и зависят от более детальных требований.
Вот мы почти пришли к общему знаменателю.
Арихитектурно, все-таки нужен какой-то «единый механизм» позволющий предотвращать коллизии при работе с общими ресурсами.
Теперь, давайте рассмотрим чуть детальнее «типовую имплементацию» Singleton
class Logger
{
private static Logger _logger = new Logger();
private Logger() {}
public static Logger GetInstance()
{
return _logger;
}
}
Вопрос: а является ли это класс Singleton? Ответ: и нет и да :)
Почему нет? Очень просто — внутри то то можно насоздавать дофига экземпляров логера:
class Logger
{
private static Logger _logger = new Logger();
.....
private static Logger _loggerN = new Logger();
private Logger() {}
public static Logger GetInstance()
{
return _logger;
}
}
Почему да? Так же просто — границы системы, где доступен один экземпляр, лежит снаружи этого класса.
Если наш Logger будет реализовывать какой-то интерфес — он перестанет быть Singleton в каких-то рамках?
class Logger: ILogger
{
...
private Logger() {}
public static ILogger GetInstance() {...}
}
Очевидно что нет.
А что произойдет, если мы сделаем такую конструкцию?
class DummyBL
{
private ILogger _logger;
public DummyBL(ILogger logger)
{
this._logger = logger;
}
}
ILogger loggerTempRef = Logger.GetInstance();
DummyBL bl1 = new DummyBL (loggerTempRef);
DummyBL blN = new DummyBL (loggerTempRef);
У нас появляется граница системы — инстанс класса DummyBL.
Вроде ничего не нарушено с точки зрения шаблона, только у нас решении появилось две границы системы: «снаружи» Logger и «вложенная» в нее граница DummyBL. Похоже на матрешку.
А что произойдет, если мы уберем одну границу, следующим образом?
class Logger: ILogger
{
...
privatepublic Logger() {}}
ILogger loggerTempRef = new Logger(); // миграция метода GetInstance() из класса Logger
DummyBL bl1 = new DummyBL (loggerTempRef);
DummyBL blN = new DummyBL (loggerTempRef);
Для самого Logger — ничего не поменялось. Как внутри него можно было плодить экземпляры, так можно и продолждать.
Для самого DummyBL — тоже ничего не поменялось. Внутри него по прежнему нельзя создавать экземпляры Logger.
Остался ли для DummyBL Logger по прежнему Singleton или нет? С точки зрения результата — да.
Дополнительно — использовали механизм DI, а не «Service Locator» встроенный в начальную имлементацию Singleton.