static creator or new with exception in constructor call

[hocjr]

I have defined a class A. This class can only be instantiated if certain business rules are met.

The following two options come to mind for implementing the business rules check:

1. Place the business rules checks in the constructor of this class and throw an exception if the business rules aren't met.

 
A a = new (A); // can throw an exception
 
class A{
 
public:
 
A::A()
{
   if( business rules aren't met)
      throw;
 
   ...
}
}
 

2. Create a static method in this class that checks the business rules and only then creates a new instance of this class .

a = A::create(); // can throw an exception
 
class A {
 
private:
A::A()
{
 
}
 
public:
static A::create()
{
   if( business rules pass ) {
      a = new(A)
      return a;
   }
   throw exception
}
 

While option (2) appears more complex, a memory alloc isn't performed until absolutely necessary. On failure of the business rules no memory dealloc is necessary.

However option (1) seems standard fare and has the advantage that anyone looking at the code understands what's happening. When the business rules fail a corresponding dealloc and exception is thrown.

Is there a recommended best practice?

Are there creation patterns that can help answer this question?

Thank you

[weaknessforcats]

The business rules should not be in the constructor for class A.

The Create function should not be a member function of class A.

I say this since it appears the business rules have nothing to do with class A but only with the creation of a class A object.

The Create function should not be a member of class A since there may be other business rules that this Create function can't handle, like what if there are multiple sets of business rules and you don't know which one to apply until run time.

The best practice is to create a factory class and the factory class is where the create method is located. Your code should look like:

Factory* f = newFactory;
A* obj = 0;
try
{
 obj1 = f->Create(ACCRUAL_BASIS);
}
catch (...)
{
    //etc...
}
delete f;          //remove the factory
//If you get here, no throw and obj is a valid pointer to a class A object.
 

Here the create method has arguments for different sets of business rules: ACCRUAL_BASIS, CASH_BASIS, etc

The factory might look like:

class Factory
{
    public:
       enum Rules {ACCRUAL_BASIS, CASH_BASIS}
       A*  Create(Rules arg);
};
 

The Factory::Create() method can use the argument to determine which set of rules to test for and can throw if the tests fail.

You might research the Factory design pattern.

[hocjr]

The business rules should not be in the constructor for class A.

The Create function should not be a member function of class A.

I say this since it appears the business rules have nothing to do with class A but only with the creation of a class A object.

The Create function should not be a member of class A since there may be other business rules that this Create function can't handle, like what if there are multiple sets of business rules and you don't know which one to apply until run time.

The best practice is to create a factory class and the factory class is where the create method is located. Your code should look like:

Factory* f = newFactory;
A* obj = 0;
try
{
 obj1 = f->Create(ACCRUAL_BASIS);
}
catch (...)
{
    //etc...
}
delete f;          //remove the factory
//If you get here, no throw and obj is a valid pointer to a class A object.
 

Here the create method has arguments for different sets of business rules: ACCRUAL_BASIS, CASH_BASIS, etc

The factory might look like:

class Factory
{
    public:
       enum Rules {ACCRUAL_BASIS, CASH_BASIS}
       A*  Create(Rules arg);
};
 

The Factory::Create() method can use the argument to determine which set of rules to test for and can throw if the tests fail.

You might research the Factory design pattern.

I did not believe the Factory design pattern was a good fit because it was only concerned with creating classes not with "should this class be created". I will reconsider it. Thank you.

[RRick]

What W4Cats is suggesting is separating the business rules from the creation of your object. I agree with him that this is a good separation of functionality.

On the other hand I have found the Builder pattern to be helpful in these cases. Factory patterns are usually passed to the object and used throughout the life of the object. In this case, since you are only interested in creating the object with the rules, you can use an intermediate builder object that deals with all the specific details and makes the final decision. For added functionality, you can pass the rules object to the builder.

[weaknessforcats]

On the other hand I have found the Builder pattern to be helpful in these cases.

Yes, indeed. I neglected to mention that.