Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Содержит, но это не голые данные, а именно domain model
G>>А что такое domain model? Интересует суть, а не цитаты из фаулера
T>domain model — это программное представление концепций предметной области, максимально к ней (области) приближенное.
Не, какие там классы, за что отвечают итп. Можно с примерами
Здравствуйте, gandjustas, Вы писали:
T>>Этот код тупо заменяется на словарь, где ключ — функция вычисляющая предикат, а в кач-ве значения — действие, которой надо выполнить, если предикат вернул true. И все, N ветвлений ушло. G>Cyclomatic Complexity — это не количество ифов, а количество decision points, если у вас один if в цикле, то Cyclomatic Complexity такого куска равно количпеству проходов цикла.
Ну тогда еще проще — уменьшаем кол-во проходов цикла до минимума и комплексити падает.
Ты неправильно понимаешь комплексити.
G>Разница Cyclomatic Complexity видна когда занимаетесь тестированием кода.
T>>Но это конечно простой случай, но к нему вполне можно свести многие ему подобные. G>Такой код чаще всего получается при изначально плохом дизайне.
Давай код, со сложностью которого у тебя возникли проблемы и посмотрим, можно ли будет уменьшить сложность.
G>>>Очень даже объективный показатель, который работает для любых языков. И полипорфизм, за который вы тут так боретесь — именно средство уменьшения Cyclomatic Complexity. T>>Не единственное средство. G>Я и не говорил что единственное.
Пример, который я привел показывает технику, как эту комплексити можно снизить не вдаваясь в делали кода. При этом, хотя по формуле сложность уменьшается, де-факто она возрастает, т.к. такой код становится сложно читать, отаживать, модифицировать, т.е. то, что обыватель называет сложностью, на самом деле возрастает, не смотря на цифирки.
Здравствуйте, Tissot, Вы писали:
T>Почему не нужен? Хранить данные — это ведь отдельная обязанность (с) gandjustas. Непоследовательно как-то получается.
В классе очереди хранение данных нам неинтересно. Поэтому такой обязанности вовсе нет.
Если бы речь шла о персистентной очереди, где вопрос хранения её состояния имел бы право на отдельное существование, то тогда да — то, что ты предлагаешь, примерно бы подошло. Но только public бы там надо было раздавать с осторожностью: первичен всё-таки контракт поведения очереди. А как там оно хранится — внутреннее дело QueueManager. Может быть, там вся очередь сериализуется в монолитный XML; может быть, там реляционная табличка; а может быть — там специально устроенная очередь на основе фич MS SQL Server. В зависимости от этого получаются совершенно разные наборы объектов: Queue, QueueItem, QueueHandle и так далее.
Глумиться над SRP — неумно. Лучше попытаться всё же понять, как опытные собаководы проводят границы ответственности, и почему это делается именно так.
А кривляния в нашем деле не помогают.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
T>>Слив засчитан. G>Ну это к MS.
Э, не. Это ты говорил, что "если нормально продизайнить систему ..."
T>>Обоснуй. Почему обязанность "хранить данные" не может быть разбита на более мелкие? T>>Только пожалуйста без аппелирования к тупости и необразованности своего собеседника. Спасибо.
G>Сначала "от протвного". Если следовать вашему пониманию SRP, то любой класс, содержащий более одного публичного члена нарушает SRP. G>Но SRP был придуман не идиотами и не прижился бы будь он настолько абсурден.
Но тем не менее, если публичным членом является метод, вы почему-то не считаете идиотами тех, кто выносит такие методы в сервисный класс. Как же так?
G>В исходном определении SRP "обязанность" модуля приравнивается к необходимости изменять модуль. Например необходимость менять класс сущности возникает только при изменении схемы данных, поэтому он не нарушает SRP.
Не, не понадобиться. Мы еще один класс заведем, с одним полем.
G>Если мы в тотже класс засунем бизнес-логику и валидацию, то уже появится три причины менять класс: изменение данных, изменение бизнес-логики, изменение валидации, поэтому будет нарушение SRP.
Поэтому валидацию мы разобъем на двести-пятьсят мелких классиков, чтобы если не дай бог понадобится что-то менять, изменения коснулись минимального объема кода. А еще лучше каждый такой класс вынести в отдельный проект. Шоб все поняли какой я крутой архитект.
G>Такой принцип не точен математически, но общую картину позволяет получить.
Жуткая какая-то картин вырисовывается.
G>>>Не-а. В таком коде класс Queue не нужен, тем более он нарушет бредовый. Класс QueueService переименовываем в Queue, оставляем пару методов Enqueue, Dequeue и еще Count и всю реализацию прячим внутри Queue. И получаем нормальную очередь.
T>>Почему не нужен? Хранить данные — это ведь отдельная обязанность (с) gandjustas. Непоследовательно как-то получается. G>"очередь" — это и есть одна обязанность класса. Для того чтобы быть полноценной очередью необходимо (и достаточно) реализиовать несколько членов, соотвествующих определенному контракту.
Вот они и будут реализованы в сервисе, а сама очередь будет хранить данные.
Здравствуйте, gandjustas, Вы писали:
T>>domain model — это программное представление концепций предметной области, максимально к ней (области) приближенное. G>Не, какие там классы, за что отвечают итп.
Классы customer, customercotainer, location, department, person
Помогло?
G>Можно с примерами
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Этот код тупо заменяется на словарь, где ключ — функция вычисляющая предикат, а в кач-ве значения — действие, которой надо выполнить, если предикат вернул true. И все, N ветвлений ушло. G>>Cyclomatic Complexity — это не количество ифов, а количество decision points, если у вас один if в цикле, то Cyclomatic Complexity такого куска равно количпеству проходов цикла. T>Ну тогда еще проще — уменьшаем кол-во проходов цикла до минимума и комплексити падает.
Ну покажите на вашем примере с кучей ифов как вы уменьшите Cyclomatic Complexity за счет таблицы.
T>Ты неправильно понимаешь комплексити.
А мне кажется что вы неправльно понимаете.
The cyclomatic complexity of a section of source code is the count of the number of linearly independent paths through the source code.
Так вот количество незвисимых путей не меняется.
G>>Разница Cyclomatic Complexity видна когда занимаетесь тестированием кода.
T>>>Но это конечно простой случай, но к нему вполне можно свести многие ему подобные. G>>Такой код чаще всего получается при изначально плохом дизайне. T>Давай код, со сложностью которого у тебя возникли проблемы и посмотрим, можно ли будет уменьшить сложность.
У меня обычно таких проблем не возникает.
T>Пример, который я привел показывает технику, как эту комплексити можно снизить не вдаваясь в делали кода. При этом, хотя по формуле сложность уменьшается, де-факто она возрастает, т.к. такой код становится сложно читать, отаживать, модифицировать, т.е. то, что обыватель называет сложностью, на самом деле возрастает, не смотря на цифирки.
На самом деле Cyclomatic Complexity при такой технике не меняется.
Здравствуйте, Sinclair, Вы писали:
T>>Почему не нужен? Хранить данные — это ведь отдельная обязанность (с) gandjustas. Непоследовательно как-то получается. S>В классе очереди хранение данных нам неинтересно. Поэтому такой обязанности вовсе нет.
А почему в entity мне должно быть это итересно? она сама по себе сохранением-то и не занимается.
Почему ради того, чтобы следовать SRP я должен выставлять все члены наружу?
S>Глумиться над SRP — неумно. Лучше попытаться всё же понять, как опытные собаководы проводят границы ответственности, и почему это делается именно так.
Есть много разных вещей, которые не могут быть вынесены за пределы сущности, т.к. они могут ломать валидность класса.
Позволять такое делать — тоже не самое большое проявления человеческого ума.
S>А кривляния в нашем деле не помогают.
Здравствуйте, gandjustas, Вы писали:
T>>>>Этот код тупо заменяется на словарь, где ключ — функция вычисляющая предикат, а в кач-ве значения — действие, которой надо выполнить, если предикат вернул true. И все, N ветвлений ушло. G>>>Cyclomatic Complexity — это не количество ифов, а количество decision points, если у вас один if в цикле, то Cyclomatic Complexity такого куска равно количпеству проходов цикла. T>>Ну тогда еще проще — уменьшаем кол-во проходов цикла до минимума и комплексити падает. G>Ну покажите на вашем примере с кучей ифов как вы уменьшите Cyclomatic Complexity за счет таблицы.
Я написал же предельно понятно. Дойду до работы, скину примерчик. Можешь померить на нем комплексити до и после.
T>>Ты неправильно понимаешь комплексити. G>А мне кажется что вы неправльно понимаете.
G>
G>The cyclomatic complexity of a section of source code is the count of the number of linearly independent paths through the source code.
G>Так вот количество незвисимых путей не меняется.
paths, a не проходов.
T>>Пример, который я привел показывает технику, как эту комплексити можно снизить не вдаваясь в делали кода. При этом, хотя по формуле сложность уменьшается, де-факто она возрастает, т.к. такой код становится сложно читать, отаживать, модифицировать, т.е. то, что обыватель называет сложностью, на самом деле возрастает, не смотря на цифирки. G>На самом деле Cyclomatic Complexity при такой технике не меняется.
Здравствуйте, Tissot, Вы писали:
T>Я уже писал, что перепечатывать текст оттуда не буду. Если вас интересуют конкретные вопросы, я готов посмотреть в книге и назвать вам номер страницы.
То есть, своих мыслей нет.
T>Не мог бы ты расшифровать RC?
Read committed
T>Если вы что-то не понятно в том, что выдает профайлер, можете выслать ваши затруднения сюда, попробуем разобраться.
Спасибо, но у меня нет никаких затруднений, так как я не использую ни ORM ни фаулеровский подход.. )
T>Почему LINQ2SQL не может быть отнесен в классическим ORM
Потому что классические ORM постороены на совсем другой идеологии и нагружены соответсвтующим функционалом. Если грубо, то они пляшут от объектной модели, в то время как LINQ, от данных.
T>и почему с его помощью нельзя построить domain model?
Можно, но не нужно, так как он для этого не предназначен и решает задачи по другому.
T>Держите свои эмоции при себе, не надо переходить на личности.
Я не перехожу, я интересуюсь. По всему видно, что не читал, просто придраться захотелось.
Здравствуйте, Tissot, Вы писали:
T>У меня есть эта книжка. Не мог бы ты назвать раздел в котором говорится об этом? Спасибо
Там об этом вся книжка, пожалуйста. )
T>Стр. 52. О том, что я не буду переписывать Фаулера, я уже писал.
Нет ты уж потрудись, если на какой-то конструктив рассчитываешь, а не просто потрындеть пришел.
Здравствуйте, Tissot, Вы писали:
T>Напомню, что речь шла о использовании domain model.
Речь шла о твоем несогласии с изложенным мнением, вместо аргументов ты сослался на Фаулера, причем довольно абстрактно.
Отсюда делаем совершенно закономерный вывод, что своего мнения не имеется.
T>Надеюсь, вопрос исчерпан?
Уже давно, я свое мнение высказал, а просто так трепаться мне не интересно.
T>Какой такой неофит? 10 лет в отрасли.
Здравствуйте, Tissot, Вы писали:
T>Дык в том-то и дело, что полиморфизма без методов — нет, а вы ж ратуете за их отсутствие в сущностях.
Ты же утверждал что читал объяснения на пальцах, что такое полиморфизм. Или опять делал это не внимательно?
T>Возможно, я не умею их готовить, но почему вы упорно продолжаете умалчивать о том, как это далать?
Где это я умалчиваю?
T>Про переходы на личности я уже писал в дугой ветке.
Можешь еще в ООН пожаловаться.
T>Ссылки, ссылки, ссылки.
В гугл сходи, набери LINQ.
T>А это наверное ваша жена написала в ваше отсутствие? T>
T>Во-вторых, добавляя новое поведение, надо его просто добавлять, а не менять старое
А это тут причем? При изменении требований новое поведение должно добавляться без изменения старого, это для тебя новость?
Здравствуйте, Tissot, Вы писали:
T>А почему в entity мне должно быть это итересно? она сама по себе сохранением-то и не занимается. T>Почему ради того, чтобы следовать SRP я должен выставлять все члены наружу?
Ты слишком много думаешь об entity.
В нормальной системе entity моделируют нижележащие данные, которые и есть предметная область. То, что сами эти данные в свою очередь являются моделью чего-то еще, в этот момент несущественно.
У данных есть только одна обязанность — "быть". Способ сохранения данных ортогонален самим данным. То, что атрибут "зарплата" не может быть меньше нуля — ортогонально структуре "карточка сотрудника". Алгоритм капитализации ФИО ортогонален структуре "Карточка сотрудника".
Эти нюансы меняются как времена года. При этом сама структура "карточка сотрудника" и ее содержимое может пережить ядерную войну.
T>Есть много разных вещей, которые не могут быть вынесены за пределы сущности, т.к. они могут ломать валидность класса.
Ты слишком много думаешь о классах. Выносить за пределы класса нужно всё, что можно вынести за пределы класса.
Поскольку публичный контракт "сущности" сводится к умению группировать данные, то 100% поведения должно быть вынесено за ее пределы.
T>Зато поднимают настроение
Заранее намекаю: злоупотребление некошерными методами подъема настроения на этом форуме чревато воспитательными мерами.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Слив засчитан. G>>Ну это к MS.
T>Э, не. Это ты говорил, что "если нормально продизайнить систему ..."
и я же сказал что получится что-то вроде validation app block. MS в свою библиотеку включили разные возможности, но это не значит что их все всегда надо использовать.
T>>>Обоснуй. Почему обязанность "хранить данные" не может быть разбита на более мелкие? T>>>Только пожалуйста без аппелирования к тупости и необразованности своего собеседника. Спасибо.
G>>Сначала "от протвного". Если следовать вашему пониманию SRP, то любой класс, содержащий более одного публичного члена нарушает SRP. G>>Но SRP был придуман не идиотами и не прижился бы будь он настолько абсурден. T>Но тем не менее, если публичным членом является метод, вы почему-то не считаете идиотами тех, кто выносит такие методы в сервисный класс. Как же так?
Я не считаю идиотами тех, кто следует SRP. Вынос метода в сервисные класс не самоцель.
G>>В исходном определении SRP "обязанность" модуля приравнивается к необходимости изменять модуль. Например необходимость менять класс сущности возникает только при изменении схемы данных, поэтому он не нарушает SRP. T>Не, не понадобиться. Мы еще один класс заведем, с одним полем.
И не сможете обеспечить его персистентность.
G>>Если мы в тотже класс засунем бизнес-логику и валидацию, то уже появится три причины менять класс: изменение данных, изменение бизнес-логики, изменение валидации, поэтому будет нарушение SRP. T>Поэтому валидацию мы разобъем на двести-пятьсят мелких классиков, чтобы если не дай бог понадобится что-то менять, изменения коснулись минимального объема кода. А еще лучше каждый такой класс вынести в отдельный проект. Шоб все поняли какой я крутой архитект.
G>>Такой принцип не точен математически, но общую картину позволяет получить. T>Жуткая какая-то картин вырисовывается.
По существу есть что сказать?
G>>>>Не-а. В таком коде класс Queue не нужен, тем более он нарушет бредовый. Класс QueueService переименовываем в Queue, оставляем пару методов Enqueue, Dequeue и еще Count и всю реализацию прячим внутри Queue. И получаем нормальную очередь.
T>>>Почему не нужен? Хранить данные — это ведь отдельная обязанность (с) gandjustas. Непоследовательно как-то получается. G>>"очередь" — это и есть одна обязанность класса. Для того чтобы быть полноценной очередью необходимо (и достаточно) реализиовать несколько членов, соотвествующих определенному контракту.
T>Вот они и будут реализованы в сервисе, а сама очередь будет хранить данные.
Еще раз. сама очередь — набор методов соотвествующих контракту. если вам требуется отдельно описывать хранение данных очереди, то вам понадобится отдельный класс QueueData и Queue будет параметризован инстансом QueueData.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>domain model — это программное представление концепций предметной области, максимально к ней (области) приближенное. G>>Не, какие там классы, за что отвечают итп.
T>Классы customer, customercotainer, location, department, person T>Помогло?
Здравствуйте, IB, Вы писали:
T>>Я уже писал, что перепечатывать текст оттуда не буду. Если вас интересуют конкретные вопросы, я готов посмотреть в книге и назвать вам номер страницы. IB>То есть, своих мыслей нет.
То есть иди на фик.
T>>Не мог бы ты расшифровать RC? IB>Read committed
Спасибо посмотрю.
T>>Если вы что-то не понятно в том, что выдает профайлер, можете выслать ваши затруднения сюда, попробуем разобраться. IB>Спасибо, но у меня нет никаких затруднений, так как я не использую ни ORM ни фаулеровский подход.. )
Нету там ничего простого и понятного, если приложение сложнее калькулятора.
А это у кого-то другого было, не у вас? Ну тогда действительно, не стоит объяснять.
T>>Почему LINQ2SQL не может быть отнесен в классическим ORM IB>Потому что классические ORM постороены на совсем другой идеологии и нагружены соответсвтующим функционалом. Если грубо, то они пляшут от объектной модели, в то время как LINQ, от данных.
Тут вам виднее, мне доводилось общаться только с hibernate-ом и linq2sql-ом. Наверное в классических как-то иначе.
T>>и почему с его помощью нельзя построить domain model? IB>Можно, но не нужно, так как он для этого не предназначен и решает задачи по другому.
Какой такой недостаток есть в LINQ2SQL-е, что он не позволяет построить domain model?
Здравствуйте, Tissot, Вы писали:
T>Классы customer, customercotainer, location, department, person T>Помогло?
А чему в предметной области соответствует customercontainer?
Вообще, как правило структура данных не совпадает с устройством предметной области. Она иногда на неё похожа, но это иллюзорное сходство.
Простейший пример — есть список кастомеров. Надо понимать, во-первых, что элементами списка являются не кастомеры, а записи о кастомерах.
Во-вторых, что сам список кастомеров в "предметной области" может быть организован, к примеру, в виде Post-it бумажек, наклеенных на whiteboard.
И в этой "предметной области" есть куча придуманных правил, например "VIP расположены в верхнем левом углу", или "если есть конфликт заказов, то выигрывает тот, который расположен выше на доске".
Моделирование самой доски с листочками в программе может дать корректный результат, а может — и некорректный.
При этом в entity "customer" появятся какие-то атрибуты, которые не имеют никакого отношения ни к реальным покупателям, ни к доске, ни к бумажкам.
Этакие "артефакты модели". Задача "максимально приблизиться к предметной области" звучит хорошо, но работает плохо. Мне больше нравится задача "придумать максимально простую модель предметной области, которая покрывает максимальное количество пользовательских сценариев".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IB, Вы писали:
T>>Стр. 52. О том, что я не буду переписывать Фаулера, я уже писал. IB>Нет ты уж потрудись, если на какой-то конструктив рассчитываешь, а не просто потрындеть пришел.
Еще раз прошу не переходить на личности. Если вам так хочется сказть мне что-то лично, мы можем встретиться и обсудить это в приватной беседе.
Здравствуйте, IB, Вы писали:
T>>Напомню, что речь шла о использовании domain model. IB>Речь шла о твоем несогласии с изложенным мнением, вместо аргументов ты сослался на Фаулера, причем довольно абстрактно. IB>Отсюда делаем совершенно закономерный вывод, что своего мнения не имеется.
Мне кажется, я уже упоминал, что обсуждается не мнение (и уж тем более не их авторство), а идеи.
P.S. Всего доброго и берегите нервы. Отвечать на ваши сообщения я больше не намерен. Если вы имеете что мне сказать, можете связаться со мной и обсудить интересующие вас вопросы и проблемы в приватной беседе, в офлайне. Всего доброго.
Мы уже победили, просто это еще не так заметно...
