Talk:Specification pattern
This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||
|
Where does criticism come from?
editThere is no citation or reference of any kind with the criticisms. They may be valid but seem to be the opinion of the author. --4.14.21.30 (talk) 14:18, 29 March 2018 (UTC)
...I have to admit I may have missed the point, but is this "pattern" just a way to do Boolean logic with a few pages of new classes and code? Cause, yeah--I've been stringing together Boolean values with logical operators for a long time. 158.111.236.74 (talk) 16:31, 6 August 2019 (UTC)
Class explosion + bad explanation
editFirst, 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.
- 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. --47.70.172.238 (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.
- -- 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 190.21.127.98 (talk) 18:17, 27 December 2014 (UTC)
UML diagram
editI've created a PNG image of the UML diagram using Dia specifically for this page. Use it if you like.
--IToshkov (talk) 11:47, 11 November 2008 (UTC)
Shouldn't the lower right-hand class be labelled NotSpecification? --132.181.52.8 (talk) 05:02, 2 July 2009 (UTC)
- Second that. — Preceding unsigned comment added by 190.21.189.24 (talk) 20:58, 30 June 2011 (UTC)
Content Doesn't make sense
editThe 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 75.146.43.241 (talk) 21:34, 26 July 2012 (UTC)
External links modified
editHello 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:
- Added archive https://web.archive.org/20110724151447/http://www.dpdk.nl/opensource/specification-pattern-for-selection-on-lists to http://www.dpdk.nl/opensource/specification-pattern-for-selection-on-lists
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}}
(last update: 5 June 2024).
- 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.
Cheers.—cyberbot IITalk to my owner:Online 03:58, 23 February 2016 (UTC)
Comparison with false
editI'm no C# guru but wouldn't one prefer to write
... && !currentInvoice.NoticeSent && ...
instead of
... && currentInvoice.NoticeSent == false && ...