By logging in to LiveJournal using a third-party service you accept LiveJournal's User agreement
Category was added automatically. Read all entries about "дизайн".
string name = "b1";
var query = IPRQuery
.From(ClassA.Description) // Создаём выборку.
.Where( a => a.Index < 10) // прореживаем выборку.
.RelatedTo(ClassB.Description) // Создаём ещё одну выборку -
// экземпляров класса ClassB, состоящих
// хоть в каком-то отношении с экземплярами выше.
// Это ограничивает и первую выборку, кстати.
.Where ( b => b.Name == name) // Прореживаем и...
// проецируем:
.Select( (a,b) => new { Name = b.Name, Index = a.Index, A = a});
foreach (var e in query) { // создание запроса и обращение к БД.
Console.WriteLine("Name "+e.Name+", Index "+e.Index+", ClassA object index "+a.Index);
}Вся эта штука создана на основе статических методов и методов расширения.class IPRQuery {
static public IPRQuery[T] From[T](IPRClassDescription[T] source) where T : IPRObject
}Он создаёт выборку. Однако мы можем добавить ещё одну выборку, и тут нам нужны методы расширения:class IPRQueryExt {
static public IPRQuery[Pair[X,T]]
From[X,T](this IPRQuery[X],IPRClassDescription[T] source) where T : IPRObject
}Это позволяет сделать сколь угодно много From через точку.class IPRQueryExt {
static public IPRQuery[T]
Where[T](this IPRQuery[T],Func[T,Bool])
static public IPRQuery[Pair[X,T]]
Where[X,T](this IPRQuery[X,T],Func[T,Bool])
static public IPRQuery[Pair[X,T]]
Where[X,T](this IPRQuery[X,T],Func[X,T,Bool])
static public IPRQuery[Pair[Pair[X1,X2],T]]
Where[X1,X2,T](this IPRQuery[Pair[Pair[X1,X2],T]],Func[X1,X2,T,Bool])
}И тд. Мы делаем вложенную структуру типов IPRQuery плоской для простого вызова функции.internal string WhereExpr(Expression expr) {
if (expr is BinaryExpression) { ...}
else if (expr is UnaryExpression) { ...}
else if (expr is ...) { ...}
throw new Exception("Unknown expression "+expr.ToString());
}А чего мучиться? ;)
gaperton, то получится хорошая система оценки дизайна программы, ещё более иерархичная, быстрее отсеивающая относительно плохие дизайны.-- у класса FAIL не должно быть реализаций. Сейчас покажу, почему.
class FAIL e
-- класс StackSlot указывает, что тип может быть сохранён в ячейке стека.
class StackSlot a
-- и реализации, который просто сигнализируют, что можно использовать
-- как элемент стека.
instance StackSlot Int
instance StackSlot Char
instance StackSlot (Pointer a)
-- А вот для Maybe потребуется FAIL, реализации которого быть не может.
instance FAIL (Maybe a) => StackSlot (Maybe a)
-- Наши новые типы для dup и over:
dup :: StackSlot a => StackOp (Stack1 stk a) (Stack2 stk a a)
over :: (StackSlot a, StackSlot b) =>
StackOp (Stack2 stk b a) (Stack3 stk b a b)
Теперь наши примитивы более безопасны и почти так же удобны.fibs = 1:1:zipWith (+) fibs (tail fibs)Без запоминания результатов каждое число Фибоначчи будет вычислять все предыдущие. Получаем экспоненциальную сложность алгоритма, как в наивной реализации.
map :: (a -> b) -> [a] -> [b] map f (x:xs) = f x:map f xs map f [] = []Итак, map по умолчанию энергичен, причем энергичен и при вычислении аргументов конструктора (:) и при вычислении конструктора списка ([] или (:)).
strictTail [] = [] strictTail (x:xs) = (x:) $! strictTail xsИ применить strictTail к результату map f list.
strictHead [] = [] strictHead (x:xs) = ((:) $! x) (strictHead xs)Вот.
