Не дал бы ни первое место, ни второе ни одному из вариантов кода в статье. Оба достаточно читаемы, понятны, и даже оформлены с отступами и разбиением на блоки, чего не скажешь о примерах из IOCCC в духе: #include <stdio.h>
#include <math.h>
double l;main(_,o,O){return putchar((_--+22&&_+44&&main(_,-43,_),_&&o)?(main(-43,++o,O),((l=(o+21)/sqrt(3-O*22-O*O),l*l<4&&(fabs(((time(0)-607728)%2551443)/405859.-4.7+acos(l/2))<1.57))[" #"])):10);}
Видимо из-за
«Так же стоит добавить, что Box2d не оперирует пикселями как данными о координатной сетке. Он изначально пректировался под использование стандарной системы Си — поэтому мы имеем метры, килограммы, секунды, и соответствующие преобразования. Сейчас я не буду углубляться подробно в эту область, просто имейте в виду, что 1 метр в представлении Box2d — это примерно 30 пикселей экранного пространства.»
Кому интересно, есть отличный проект Topshelf: topshelf-project.com/
Позволяет стартовать сервис как консольное приложение, так и в виде windows service, предоствляю удобный механизм установки и запуска. Плюс поддерживает горячую замену кода сервиса, а также работает с Mono.
> IQueryable Pipes and Filters
На мой взгляд, IQueryable хоть и делает вид, что реализует механизм Pipes and Filters, но по факту его не реализует в полной мере, выступая именно в роли Query Object, в отличии от IEnumerable. Более того, насколько я знаю, единственная технология реализующая LINQ на 100% — это Linq2Object, а следовательно рано или поздно абстракция торчащего наружу IQueryable начинает течь, что порождает различные костыли.
Кроме того, такой IQueryable Repository может приводить ещё и к ошибкам, связанным с тем, что этот IQueryable актуален лишь когда есть соединение с базой данных. Причем мы не можем контролировать время жизни этого объекта. Вполне может получиться, что какая-то часть системы попытается выполнить запрос уже после того, как сессия/контекст/что-либо ещё была уничтожена.
И это основные отличия от Query, описанного в оригинальной статье Александра. Это не Query object. Это скорее обёртка над Query Object, инкапсулирующая конкретный запрос, и по сути своей реализующая Specification.
Во варианте Тимура, кстати, тоже есть проблема с тем, что IQueryFor<> теоритически случайно можно отдать на сторону, потеряв над ним контроль. Хотя тут основная магия будет именно в IoC контейнере, из которого будет получен LinqProvider.
1) Ну в этом абстрактром примере с 9000 методами, как я предполагаю, речь шла о публичных методах. Мне себе это, конечно, сложно представить — но по сути своей это вполне допустимо. Т.е. куча методов GetEntityOneBySomething, GetEntityTwoBySomethingElse… GetEntityNineThosandById(). Ну или не 9000 сущностей, а 900 сущностей по 10 методов.
Вероятно вы правы насчёт класса с сотней методов. Да, выглядит, как типичный god object. Но при этом вероятно и не нарушает ни SRP (ведь у репозитория одна обязанность — возвращать объекты из коллекции и добавлять в коллекцию), ни ISP(если только мы не предполагаем, что часть сущностей модели у нас лежат в SQL, а другая часть — в XML).
2) Если два программиста одновременно откроют этот файл, и один программист перенесёт существующий метод в начало файла, а второй в начале же файла напишет новый метод, то почти наверняка будет неизбежный конфликт. Пример надуманный, конечно, но я уверен, что если достаточное количество людей будет параллельно работать над одним файлом, то разрешение конфликтов для них станет каждодневным привычным делом.
> В случае Query приложение знает только про интерфейс IQueryFactory
И про все Query? Т.е. по сути единственное отличие IQueryFactory/Query от IRepository/ISpecification лишь в том, что IRepository помимо выборки предполагает ещё и добавление объектов в коллекцию.
А в случае с предложенным Тимуром методом, получается, что приложение знает о IQueryFactory и обо всех Criterion?
Ну разве что в этом случае спецификация разбита на параметры и, собственно, на саму спецификацию. Это, конечно, здорово, что Criterion можно использовать повторно, но зачем? При этом программисту всегда приходится помнить, для каких критерионов/сущностей в системе реализованы запросы. Или же я чего-то не понимаю?
> Нет ли проблемы с архитектурой проекта, если количество методов в репозитории превысило 9000?
Есть. Собственно поэтому и предложена концепция разбиения репозитория на множество query объектов.
> В чем преимущество?
На самом деле в этом совершенно оторванном от реальности примере, преимущество будет в том, что команда столь огромного проекта скорее всего будет так же велика. В случае со множеством файлов будет проще мерджить изменения, внесенные командой :-)
> Каким образом 18000 классов легче тестировать, чем один класс с 9000 методами?
Хороший вопрос, кстати. На самом деле ничуть не легче, особенно если оригинальный репозиторий написан правильно и имеет минимальные зависимости.
3. Избавляемся от каши private/protected методов, которые вызываются в произвольных публичных методах god object'а, что позволяет лучше понимать зависимости и поведение конкретных методов за счёт лучшего разграничения контекстов.
В качестве мистера «никто» может выступить программист, который влез в этот код, когда вы уже год как уволились. Есть метод, у метода есть контракт — метод не изменяет переданный в него объект. Это значит, что при вызове этого метода мне не нужно блокировать объект на запись, если идёт работа в многопоточном окружении.
Другое дело в том, правильно ли это? Тут легко выстрелить себе в ногу, если кто-то изменит сигнатуру метода (хотя если кто-то это делает, не проверив все использования метода, то нужно ему бить по рукам), удалив этот контракт.
В C#/Java в этом случае действует презумпция виновности — если мы передаём в метод mutable объект, то предполагаем, что метод рано или поздно может изменить этот объект, поэтому обо всех блокировках лучше позаботиться заранее, или же в качестве аргумента этого метода принимать immutable обёртку над исходным объектом.
Java классы по 10000 строк кода? Или класс, число строк в методах которого превышает 10000?
В первом случае, мне кажется, что это классический big ball of mud, хотя если они этими классами умудряются не нарушить SRP и ISP, то это здорово (хотя я думаю, что если программист решился на такое, то это подразумевает, что больше никто и никогда в этот класс не полезет).
Во втором случае — это абсолютно нечитабельное самоубийство. Потребуется немало времени тому, кто попытается разобраться, что же там происходит. И, думаю, что в этом случае это метод почти наверняка не покрыт тестами, так как тестировать такой метод невероятно сложно.
Вообще, если предположить, что дело в Яндекс.Баре, и что его устанавливают неопытные простые юзеры, то это может быть ещё одним объяснением столь странного содержания утекших смсок.
Должен заметить, что конструкцию «yield return» нужно использовать аккуратно. В частности, недавно получил неожиданный BadImageFormatException на такой код: gist.github.com/1085737
С моей точки зрения код валиден, но разбираться в том, почему это не работает, я предоставил ребятам из Microsoft, написав баг-репорт. Я буду премного благодарен тому, кто разъяснит мне причину этого исключения.
Как я понимаю, это дело практики (как и почти все остальные занятия), т.е. нужно ежедневно под метроном, постепенно увеличивая скорость в течение занятия, начиная с очень медленного темпа, играть какие-нибудь партии.
Что интересно в случае, когда у нас много маленьких сообщений, JSON компактее BSON.
"{foo:'bar'}" — 11 байт, в BSON'е это 18 байт.
"{cid:1,uid:12,x:10,y:20}" — 24 байта так, и 53 в BSON.
"{cid:1,uid:12,c:[10,20]}" — 24 байта, и 61 в BSON.
#include <stdio.h>
#include <math.h>
double l;main(_,o,O){return putchar((_--+22&&_+44&&main(_,-43,_),_&&o)?(main(-43,++o,O),((l=(o+21)/sqrt(3-O*22-O*O),l*l<4&&(fabs(((time(0)-607728)%2551443)/405859.-4.7+acos(l/2))<1.57))[" #"])):10);}
«Так же стоит добавить, что Box2d не оперирует пикселями как данными о координатной сетке. Он изначально пректировался под использование стандарной системы Си — поэтому мы имеем метры, килограммы, секунды, и соответствующие преобразования. Сейчас я не буду углубляться подробно в эту область, просто имейте в виду, что 1 метр в представлении Box2d — это примерно 30 пикселей экранного пространства.»
Позволяет стартовать сервис как консольное приложение, так и в виде windows service, предоствляю удобный механизм установки и запуска. Плюс поддерживает горячую замену кода сервиса, а также работает с Mono.
На мой взгляд, IQueryable хоть и делает вид, что реализует механизм Pipes and Filters, но по факту его не реализует в полной мере, выступая именно в роли Query Object, в отличии от IEnumerable. Более того, насколько я знаю, единственная технология реализующая LINQ на 100% — это Linq2Object, а следовательно рано или поздно абстракция торчащего наружу IQueryable начинает течь, что порождает различные костыли.
Кроме того, такой IQueryable Repository может приводить ещё и к ошибкам, связанным с тем, что этот IQueryable актуален лишь когда есть соединение с базой данных. Причем мы не можем контролировать время жизни этого объекта. Вполне может получиться, что какая-то часть системы попытается выполнить запрос уже после того, как сессия/контекст/что-либо ещё была уничтожена.
И это основные отличия от Query, описанного в оригинальной статье Александра. Это не Query object. Это скорее обёртка над Query Object, инкапсулирующая конкретный запрос, и по сути своей реализующая Specification.
Во варианте Тимура, кстати, тоже есть проблема с тем, что IQueryFor<> теоритически случайно можно отдать на сторону, потеряв над ним контроль. Хотя тут основная магия будет именно в IoC контейнере, из которого будет получен LinqProvider.
Вероятно вы правы насчёт класса с сотней методов. Да, выглядит, как типичный god object. Но при этом вероятно и не нарушает ни SRP (ведь у репозитория одна обязанность — возвращать объекты из коллекции и добавлять в коллекцию), ни ISP(если только мы не предполагаем, что часть сущностей модели у нас лежат в SQL, а другая часть — в XML).
2) Если два программиста одновременно откроют этот файл, и один программист перенесёт существующий метод в начало файла, а второй в начале же файла напишет новый метод, то почти наверняка будет неизбежный конфликт. Пример надуманный, конечно, но я уверен, что если достаточное количество людей будет параллельно работать над одним файлом, то разрешение конфликтов для них станет каждодневным привычным делом.
И про все Query? Т.е. по сути единственное отличие IQueryFactory/Query от IRepository/ISpecification лишь в том, что IRepository помимо выборки предполагает ещё и добавление объектов в коллекцию.
А в случае с предложенным Тимуром методом, получается, что приложение знает о IQueryFactory и обо всех Criterion?
Ну разве что в этом случае спецификация разбита на параметры и, собственно, на саму спецификацию. Это, конечно, здорово, что Criterion можно использовать повторно, но зачем? При этом программисту всегда приходится помнить, для каких критерионов/сущностей в системе реализованы запросы. Или же я чего-то не понимаю?
Есть. Собственно поэтому и предложена концепция разбиения репозитория на множество query объектов.
> В чем преимущество?
На самом деле в этом совершенно оторванном от реальности примере, преимущество будет в том, что команда столь огромного проекта скорее всего будет так же велика. В случае со множеством файлов будет проще мерджить изменения, внесенные командой :-)
> Каким образом 18000 классов легче тестировать, чем один класс с 9000 методами?
Хороший вопрос, кстати. На самом деле ничуть не легче, особенно если оригинальный репозиторий написан правильно и имеет минимальные зависимости.
Другое дело в том, правильно ли это? Тут легко выстрелить себе в ногу, если кто-то изменит сигнатуру метода (хотя если кто-то это делает, не проверив все использования метода, то нужно ему бить по рукам), удалив этот контракт.
В C#/Java в этом случае действует презумпция виновности — если мы передаём в метод mutable объект, то предполагаем, что метод рано или поздно может изменить этот объект, поэтому обо всех блокировках лучше позаботиться заранее, или же в качестве аргумента этого метода принимать immutable обёртку над исходным объектом.
Я имел в виду «число строк каждого из методов».
В первом случае, мне кажется, что это классический big ball of mud, хотя если они этими классами умудряются не нарушить SRP и ISP, то это здорово (хотя я думаю, что если программист решился на такое, то это подразумевает, что больше никто и никогда в этот класс не полезет).
Во втором случае — это абсолютно нечитабельное самоубийство. Потребуется немало времени тому, кто попытается разобраться, что же там происходит. И, думаю, что в этом случае это метод почти наверняка не покрыт тестами, так как тестировать такой метод невероятно сложно.
P.S. Яндекс.Бар — это такое же расширение, как и всё, что вы перечислили.
С моей точки зрения код валиден, но разбираться в том, почему это не работает, я предоставил ребятам из Microsoft, написав баг-репорт. Я буду премного благодарен тому, кто разъяснит мне причину этого исключения.
"{foo:'bar'}" — 11 байт, в BSON'е это 18 байт.
"{cid:1,uid:12,x:10,y:20}" — 24 байта так, и 53 в BSON.
"{cid:1,uid:12,c:[10,20]}" — 24 байта, и 61 в BSON.