Talk:Specification pattern

From Wikipedia, the free encyclopedia

[edit] Class explosion + bad explanation

First, this article has a pretty bad explanation and needs to be cleaned up. I'll try, but I'm not a design pattern expert by any means, even though I am a CS student and have taken a software engineering course. It just seems like this design pattern is a big absurd in implementing boolean logic through classes. Such operators exist in every language, why would classes need to exist to perform their function? And then on top if this, you need even more classes to implement every little detail of specification needed. If anyone has some good criticisms, maybe this could have a criticism section too... (a web search didn't turn up anything, but I haven't checked any journals) HebrewHammerTime 09:19, 26 September 2007 (UTC)

Often times patterns seem quite useless unless you run into the problem that the pattern solves. The specification pattern allows for functional-style (no side effect) boolean business logic recombination that is easily testable and reused in the business tier *or* in the presentation tier (check the reference to the Domain Driven Design book). In your reference to 'such operators exist in every language' I'd like to point out that you don't have set-up or tear-down ability for Boolean operators in many languages (overloading the 'and' and 'or' symbols). Given that, you would have to put set up/tear down code in a procedure style script with the rest of your Boolean logic (e.g. you would put perhaps database retrieval code to populate the classes in question, along with the rest of whatever other objects you need for attribute population, along with traversal/sorting of any internal representations if the class has internal array properties). In the example there is a 'collection' specification, which would in theory need to have an internal collection of whatever the business rules consider to be 'sent notices'. This could be notices that have been sent certified mail only, and not notices that are in the database and have been sent, but not as certified. The set up for such a business rule would need to be regurgitated every time you wanted to chain that rule with another one. In short, if you have Boolean rules that get recombined often and are reused in multiple places (aka specifications), you have a tool in the specification pattern. In reference to your 'class explosion' comment, you'll find that class explosion happens when people over use 'is-a' aka inheritance relationships. The specification pattern stands in a 'has-a' composite/delegate relationship with real-world objects, so the explosion doesn't happen in practice. In popular ORM frameworks such as Hibernate you have a 'domain' of classes that represent real-world things. Then you have the logic that controls that domain (i.e. employees in certain labor categories must get over-time by law, when working over 40 hours). That rule that I just said should have only one instance where the code resides (see http://en.wikipedia.org/wiki/Separation_of_concerns). If you use that rule in many different classes, you'll quickly find out that you have code duplication. You may then make some kind of external class/function that gets called whenever some kind of 'saving' of a payroll happens. You may then run into places where you don't want to save based on that rule, you just want to use that rule as the basis of another rule (e.g. a comp-time rule that only gets applied to 'over-time' employees). At this point you should see that your logic needs to be made side effect free, encapsulated, and recombinable with other logic. Now you have the specification. As a side note, I can't see why you would want to use this pattern in a more dynamic and functional language like lisp.

--Wavell2003 (talk) 15:09, 20 March 2008 (UTC)

The distinction between this and Interpreter pattern is unclear to me. Perhaps this is a special case of Interpreter?

Dubwai (talk) 22:03, 25 January 2008 (UTC)

The Interpreter pattern allows for a lot more than just chaining of Boolean logic. In the Interpreter pattern you have the ability to parse strings and apply whatever logic you want (not just boolean) to the classes that are created. The Specification pattern is more similar to the strategy pattern.

--Wavell2003 (talk) 15:09, 20 March 2008 (UTC)