Talk:Specification pattern

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer science (Rated Start-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.

Class explosion + bad explanation[edit]

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 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)
Of course I would use this pattern in a functional language. It's just not as apparent, because you can do it in a few lines of code instead of a mess like the one we have right now. ("simplified"... yeah...) But I am torn up if replacing the code with a shorter, clearer, functional variant would be a good idea, as fewer people understand Lisp or Haskell. -- (talk) 01:28, 20 November 2015 (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)
-- Second that Dubwai The Specification as explained here is special case of Interpreter. To quote the first article from the list "This effectively creates an interpreter [Gang of Four] for the specification. The "language" being interpreted allows us to describe a composite specification." and connection with Interpreter should be made clear. — Preceding unsigned comment added by (talk) 18:17, 27 December 2014 (UTC)

UML diagram[edit]

I've created a PNG image of the UML diagram using Dia specifically for this page. Use it if you like.

Specification UML.png

--IToshkov (talk) 11:47, 11 November 2008 (UTC)

Shouldn't the lower right-hand class be labelled NotSpecification? -- (talk) 05:02, 2 July 2009 (UTC)

Second that. — Preceding unsigned comment added by (talk) 20:58, 30 June 2011 (UTC)

Content Doesn't make sense[edit]

The text is confusing at one point, and talks about a previously implemented class, which is not linked or shown anywhere. It looks like this may be copied from some other source, and as such may be plagerized.

"We previously defined an OverdueSpecification class" — Preceding unsigned comment added by (talk) 21:34, 26 July 2012 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just added archive links to one external link on Specification pattern. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

You may set the |checked=, on this template, to true or failed to let other editors know you reviewed the change. If you find any errors, please use the tools below to fix them or call an editor by setting |needhelp= to your help request.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

If you are unable to use these tools, you may set |needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.

Cheers.—cyberbot IITalk to my owner:Online 03:58, 23 February 2016 (UTC)

Comparison with false[edit]

I'm no C# guru but wouldn't one prefer to write

   ... && !currentInvoice.NoticeSent && ...

instead of

   ... && currentInvoice.NoticeSent == false && ...

? Uligerhardt (talk) 08:58, 10 March 2016 (UTC)