This weeks pattern is the Specification Pattern. We will spend this week reviewing this pattern, how it is used and what its intent is for. For some more in-depth definition you can see here and Here are some useful descriptions, but to appreciate this we will review the intent and possible solutions and applications for this pattern in everyday work.
Here is the intent of the Specification pattern: “ to separate the logic for (e.g.) filtering an entity from the entity itself.”
Example application for this pattern has been to support filtering as a pluggable entity “collection” of specifications. The implementation details as things mature are apparent with generics and expression tree’s and event the IQueryable<> interfaces against OR/M layers.
The main benefits of this pattern are
1 – Loose coupling of the filter logic from the objects being filtered,
2- Single responsibility: Filtering is essentially a first class citizen and also can exist in a decoupled state for better testing and independent improvement
3 – Composition of specifications allows for reuse and complex nested specifications for easier maintenance.
This weeks pattern is the FlyWeight Pattern. We will spend this week reviewing this pattern, how it is used and what its intent is for. For some more indepth definition you can seeandare some usful descriptions, but to appriciate this we will review the intent and possible solutions and applications for this pattern in everyday work.
Here is the intent of the flyweight pattern: “The intent of this pattern is to use sharing to support a large number of objects that have part of their internal state in common where the other part of state can vary.”
Example application for this pattern has been a text editor abstracting out the state of each character as glyphs. This is a nice concept but really limits the true application for this pattern across the board. When I see this pattern I think caching and this is also very similar to a connection pooling type of resource manager. I think the big difference here is these share some state while other parts are unique making each type a potential hybrid. This week in exploring this pattern think about applications for it. What interesting applications can you think of for this pattern, it seems with the advent of large memory and fast processors this hasn’t been considered except in memory condious applications with limited resources.
A Skyline query is one of the most useful but least obvious data programming patterns. When you have a set of data and a query with 2 constraints that are conflicting, the output of this is the “Skyline” Query. If you want to thing about what skyline means and why it describes this issue take the example of searching for cars to drive, and lets say you want the biggest car with the best gas mileage. These two constraints are conflicting since as cars get bigger, gas mileage usually goes down, but a skyline query essentially runs this query across a set of data and then grabs the tops of the skylines. This would take a cluster of data and grab the top 2 or 3 in that set, then move along to find the next set, this way you can give the user choices without having to come up with an artificial weight or
A more realistic example would be searching for a house that is the cheapest cost, that is the biggest, and say closest to where you work. This is one of the rare data patterns that has so many real world applications it is not commonly known below we will show an implementation of an efficient algorithm shown in this paper to offer stellar performance.
They showed that the best performance for a multi-dimensional skyline processor is a Block – Nested Loop.
Here is some psudo-code with implementation coming next. I’ll show brute-force then also
an implementation with the block-nested loop for T-SQL..
1: M – Input of dimensional points
2: R output of dimensional points
3: T temporary file for dimensional points
4: S set of dimensional points
5: p < q point p is dominated by point q
7: function SkylineBNL(Input)
9: Output = 0;
10: Temp = 0;
12: CountIn = 0;
13: CountOut = 0;
18: foreach p in Set
22: save(Output, p), Release(p)
25: TimeStamp(p) = CountOut;
27: foreach(q in Set)
29: if(p>q) release (p) break;
30: if(p<q) then reelase(q);
34: save(Temp,p), release(p)
35: CountOut ++;
37: //keep it running to iterate through entire sets.
38: if(Main == empty)
40: Main = Temp;
47: foreach(p in Set)
49: save(Output,p), release(p)
52: return Output;