Систематизация автоматизации

Ну и YAGNI конечно

2011-09-20T23:02:23.177+03:00

Ну и YAGNI конечно

Как учебный пример, может и нет. Но в качестве при...

2011-09-20T23:01:09.927+03:00

Как учебный пример, может и нет. Но в качестве примера боевого коде - why not, вполне. Главное, не забывать про DRY и KISS при этом :)

Спасибо за ответ :) Я понимаю, что нужно использов...

2011-09-20T18:33:08.227+03:00

Спасибо за ответ :)
Я понимаю, что нужно использовать эти принципы с самого начала проектирования системы. Я сейчас тренируюсь в agile-разработке, и, соответственно, применяю все этапы проектирования: диаграммы, потом тесты, а потом уже код. И это буквально "вынуждает" писать гибкий код, используя все эти архитектурные принципы.
Это я к тому, что часто бывает так: спроектированная поначалу бизнес-сущность выглядит как один модуль, а на этапе кодирования приходится разделять ее на несколько более мелких. Опять же, следуя принципу SRP.
Пример, который я приводил в комментарии выше, является хорошим приемом организации SRP на уровне кодирования?

IFeelGood, Слово "макстимально" тут лиш...

2011-09-20T12:33:07.434+03:00

IFeelGood,

Слово "макстимально" тут лишнее. Что чрезмерно - то не здраво, и использование принципов ради принципов не дает хорошего результата. Добавление вороха лишних абстракций разделит обязанности, но привнесет дополнительную сложность, с которой вам придется бороться с куда большим усердием, чем с, о боже, реализацией active record :)

Для оценки качества исполнения принципа SRP могу порекомендовать попытаться сформулировать обязанности класса обычным человеческим языком. Если если получается средних размеров повесть, значит все плохо :) В идеале все должно вписываться в одном предложение.

Кроме того, никоим образом эти принципы не рулят правилами организации приватных внутренностей классов. Тут уже каждый сам для себя решает что и как делать, главное, чтобы снаружи все вело себя предсказуемо, а зависимая логика может быть и спрятана, и заведена снаружи в виде неких дополнительных компонентов. Подумайте о том, как бы будете тестировать эту логику - это тоже поможет все грамотно раздедить.

Ну и последнее: штука в том, что сами по себе синтаксические конструкции со словом class в начале не всегда соответствуют логическому понятию класса объектов. Код - это достаточно низкий уровень дизайна системы из за бедности современных языков программирования. Классический пример - понятия agregate roots и entities в сравнениии с value objects в паттернах DDD: единственная точка входа в логику - это корень агрегата, который за собой может прятать с десяток других классов, но вместе образовывать тот самый единый класс в терминах теории ООП. Или взять тот же aggregate root, но реализованый в виде event source-а. Т.е. к этому агрегату добавляется еще пачка связанных событий и какой-то странный код по их обработке. В квадратиках все выглядит очень просто, но в коде получается куча синтаксического мусора. Кроме того, даже такие высокоуровневые логические понятия, как агрегаты тоже могут составлять конструкции еще более высоких уровней - домены логики, модули систем и т.д.

Все это к тому, что не стоит рассматривать эти архитектурные принципы исключительно на уровне правил кодирования некой логики в виде каких-то конкретных языковых конструкций какого-то конкретного языка программирования, которые по странному стечению обстоятельств поддерживают понятие интерфейсов и прочих приватных методов. Пользуйтесь ими на всех уровнях дизайна вашей системы, и тогда в этом действительно будет смысл.

Вопрос по принципу SRP (хочется уточнить, правильн...

2011-09-20T11:33:29.842+03:00

Вопрос по принципу SRP (хочется уточнить, правильно ли я понимаю принцип?):
Нужно максимально стремиться специализировать класс, например, отделить бизнес-логику от сохранения данных в БД.
Также следует специализировать все открытые методы класса, которые составляют его интерфейс. Например, метод: int CalculateDiscount(int price) - вычисляет скидку и ничего более.
Если же для успешной реализации такого метода требуется дополнительная бизнес-логика, то ее нужно вынести в отдельные вспомогательные private-методы, которые не являются открытым интерфейсом класса.

"Но откуда-то из вашего кода начинает нести о...

2011-01-09T21:15:22.848+02:00

"Но откуда-то из вашего кода начинает нести отборным code smell" класс, поржал, спасибо :)))

В Nemerle есть implicit match , можно писать так: ...

2010-12-21T15:46:59.095+02:00

В Nemerle есть implicit match , можно писать так:
def qs(l)
{
| [] > []
| x :: xs => ...
}

Спасибо за статью.

2010-12-01T11:33:36.471+02:00

Спасибо за статью.

Странная у Вас на сайте дата: Latest update: 27.10...

2010-11-24T18:24:06.265+02:00

Странная у Вас на сайте дата:
Latest update: 27.10.2008

Прочитал с огромным интересом почти весь блог, а в...

2010-08-31T20:53:28.256+03:00

Прочитал с огромным интересом почти весь блог, а в этой серии, ещё не дочитав первый пост, понял, что в эту архитектуру идеально вписывается CoushDB. Она хранит все данные в общей куче (одна база данных - одно B-дерево) в виде (по крайней мере внешне, со стороны потребителя) пар "идентификатор"->"JSON сериализация объекта, включая вложенные (списки и т. п., в общем дерево целиком, а не только его корень)", при этом эту сериализацию она понимает и позволяет искать по значению свойств. Основной механизм получения данных - или "GetById", или так называемые View (JavaScript функции с активным использованием map/reduce функций, индексы для которых обновляются при каждой операции). "Бесплатные плюшки" - встроенная по дефолту версионность, репликации, вертикальная масштабируемость, простой REST интерфейс. Кого заинтересовалo CQS - настоятельно рекомендую попробовать CouchDB.

Statji super! Avtor Molodez! nu ochenj interessno....

2010-07-16T15:48:03.712+03:00

Statji super! Avtor Molodez! nu ochenj interessno.
no! ne izabretaete li Vi velosiped? zachem tak slogno? moget validation ne ochne horoshij primer dlja primenenija DSL? nu ne budu ja vremja tratitj chtobi delatj vse tak universalno. dumaju eto prosto lishnee. privedite pogalusta drugie primeri oblasti primenenija DSL. nikogda s etim ne rabotal i ne znaju kak i s chego nachatj i nugno li mne eto v moih projektah. Ogromnoe Spasibo za statji i za otveti! Vsego Vam nailuchego!

Thanks! Good job.

2010-04-20T16:11:13.880+03:00

Thanks! Good job.

Спасибо, поправил :)

2010-04-12T13:27:59.999+03:00

Спасибо, поправил :)

Поправьте, пожалуйста: Принцип замещения Лисков: ....

2010-04-12T13:11:54.155+03:00

Поправьте, пожалуйста:
Принцип замещения Лисков:
...поведение P не будет меняться, если o1 заменить на o2.
вы перепутали о1 и о2 местами,
и для понимания будет лучше, если, как в Википедии, объекты типа (Type) и подтипа (Subtype) обозначить oT и oS соответственно.

Не работает на Guid, DateTime

2009-12-21T09:50:02.749+02:00

Не работает на Guid, DateTime

Вот еще встретилось и может быть полезно http://my...

2009-12-01T12:12:24.430+02:00

Вот еще встретилось и может быть полезно http://myshop.codeplex.com/

Семпл по мотивам CQS

К какому именно случаю вы попытались все это приме...

2009-11-20T01:04:21.928+02:00

К какому именно случаю вы попытались все это применить? Возможно, проблема была именно в не совсем подходящем примере.

Еще, возможно вы найдете ответы на некоторые вопросы здесь. Ну и пройдитесь еще раз по указанным ссылкам.

Пораскинув мозгами, и попробовав наструячить пару ...

2009-11-17T14:40:08.676+02:00

Пораскинув мозгами, и попробовав наструячить пару тестовых примеров по вашему предложению, мне стало уже 100% понятно, что кроме геморроя предложенный вами(или не вами) способ, больше ничего не приносит.
То есть если мы даже хоть какой, то мнимый плюс при работе с моделью. То этот плюс превращается в огромный минус, когда дело касается реализации данных методов.
И в целом мне непонятна ситуация, зачем такой огород городить. Например, выделение OLAP служит для увеличения скорости построения отчетов, и основной костыль с которым все мирятся – что OLAP база может содержать устаревшую информацию.
Но в вашем случае вы делает 2 базы и еще Notify между ними, что бы их держать в одинаковом состоянии, но зачем это надо, когда можно используя инструменты базы данных, такие как View и StoreProc реализовать точно такую, же систему, то есть у вас структура базы одна, но для приложения она совершенно другая.

например, так. хотя, все зависит от случая. class...

2009-11-12T16:43:15.550+02:00

например, так. хотя, все зависит от случая.

class QuarterDiscount : Entity
{
Percentage Percentage { get; set; }

public UpdatePercentage(Percentage newValue)
{
Percentage = newValue;
}

public Amount Apply(Amount amount)
{
return amount * percentage;
}
}

Игорь, можете поподробнее описать QuarterDiscount....

2009-11-12T16:35:58.045+02:00

Игорь, можете поподробнее описать QuarterDiscount.

To C...R...a...S...H Тут следует отличать действи...

2009-11-12T13:34:17.198+02:00

To C...R...a...S...H

Тут следует отличать действительно отчетные данные, которые никак не влияют на логику домена, и данные, которые домену нужны.

Исходя из этого, скажем, в модели бы появилась сущность типа какой-нибудь QuarterDiscount и любой новый заказ бы влиял на ее состояние. И даже больше - изменения ее состояния регистрировались в каких-нибудь отчетах :)

А вообще, вы затронули интересную тему, о которой я умышлено не написал.

Вся эта система работает хорошо, когда она, скажем так, не развивается. Когда вы запускаете механизм, все данные куда-то ходят, все где-то аккумулируется и таким образом поддерживается актуальное состояние системы.

А как быть, если, скажем на любом из уровней, добавляются новые типы "аккумуляторов", которые должны работать так, как если бы они были в системе последние лет 10...

Вот тут есть о чем поговорить :)

2Meowth: А никто и не говорит об абсолютной новиз...

2009-11-12T13:23:17.327+02:00

2Meowth:

А никто и не говорит об абсолютной новизне подхода. Тут все дело лишь в точке приложения этого подхода: если приложение сильно data-centric, то все будет делаться на основе Master/Subscriber. Если же приложение behaviour-centric, то это будет называться CQS.

Нужно отметить, что схема Master/Subscriber вполне себе может сочетаться и с CQS на уровне кода. Оно все и так сильно оторвано друг от друга. Никаких догм здесь нет - во всем следует быть прагматиком :)

Well, I can't fully agree with this opinion. I...

2009-11-12T13:15:12.235+02:00

Well, I can't fully agree with this opinion. I.e. modern languages like C# can't check the behaviour aspects of the inheritance. Thats why the Design by contract approach with automated theormes proving is still on the very early stages of implementation.

Игорь, а как ваша архитектура будет обслуживать та...

2009-11-12T13:02:02.404+02:00

Игорь, а как ваша архитектура будет обслуживать такие требования бизнеса, которые строятся на отчетной информации.
Наприме: Клиент автоматически получает скидку, равную 3% от средней стоимости заказов за последний год(месяц, квартал, эру...).

На самом деле, схема репликации Master(RW) - Subsc...

2009-11-11T16:39:25.124+02:00

На самом деле, схема репликации Master(RW) - Subscriber(RO) (для снижения нагрузки) организует что-то подобное, только там по прагматическим причинам используются RDB и для того звена, что у вас названо ReportingDB.
Подход в данном случае интересный, но спорный.