Jump to content
  • Advertisement
Sign in to follow this  
Concentrate

Is this a design pattern

This topic is 3037 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

You guys have probably seen this, just wondering if this is a certain design pattern :

class B
{
public:
virtual void compute()const{
if(!preCondition()) { /* throw precondition error */ }
doIt();
if(!postCondition()){ /* throw postcondition error */ }
}
private:
virtual void doIt()const = 0;
virtual bool preCondition()const{ return true; }
virtual bool postCondition()const{ return true; }
};

class D : public B
{
void doIt()const{
//do stuff
}
bool preCondition()const{ return _isEverythingOk(); }
};

Share this post


Link to post
Share on other sites
Advertisement
I've seen it before (when compute() is non-virtual though). I don't know if it is a desgin pattern, but that isn't necessarily important. I believe there are some languages which support decorating functions with pre and post conditions automatically.

Share this post


Link to post
Share on other sites
Quote:
Original post by rip-off
I've seen it before (when compute() is non-virtual though). I don't know if it is a desgin pattern, but that isn't necessarily important. I believe there are some languages which support decorating functions with pre and post conditions automatically.


Thanks, If it was, I thought there would be more information on this pattern,
thats all. Thanks again.

Share this post


Link to post
Share on other sites
Aspect Oriented Programming is the search term you're looking for. This can also be considered a... rigid sort of Decorator pattern in practice.

Share this post


Link to post
Share on other sites
Quote:
Original post by jonathanjansson
The way you implemented Design by Contract in your example is called Template Method Pattern.


A little note here: pre- and post- condition checking is a topic by itself. While the code may look like some design pattern, it is completely unrelated in function and purpose.

Pre and post conditions, regardless of how they are coded (as virtuals, in documentation, by QA manual testing, static analysis or automated proof) asserts that class invariants are preserved, or fails. Failure here is typically regarded as catastrophic - if any of conditions fails, the code cannot handle it. Think of temperature sensor returning -273 degrees. The AC cannot handle that, something went wrong. AC must then shutdown, since sensor could be broken, and further operation could cause additional damage. Or, code would contain specific handler for temperatures below -20 degrees which would then also be listed as operational range.

This was explored into detail with Ada, which was designed for precisely such purposes.

Invariant validation can be performed in many ways and much of it can be done automatically (not necessarily in C++).

Also worthy noting is that throwing a run-time exception is only practical if that exception is not and cannot be handled. If anyone is allowed to catch and supress it, it defeats the purpose.

Ideally, predicate violations would be reported during compile-time. There actually exist languages where "if it builds, it's works correctly".

In practice, this type of rigorous checking is impractical for most purposes, so it's applied only for very niche purposes.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!