Rick Gutleber wrote:
> Does it really make sense for allow_transactions() to be part of the
> policy or should it be a bool option passed in to insertfrom( )?
>
> The reason I ask is because it seems silly to have to have two different
> InsertPolicy objects that differ only in whether transactions are
> allowed or not.
There are patterns to allow the extra attribute without creating a
parallel class hierarchy. I'd use traits:
template <class AccessController = Transaction>
class MyPolicy
{
public:
typedef AccessController access_controller;
...
Then you could create a no-op NoTransactions class with the same
interface as Transaction, so that MyPolicy<NoTransactions> would be
MyPolicy without transactions. This relieves from insertfrom() the
burden to care about transactions:
InsertPolicy::access_controller ac(&conn_);
A bool parameter to insertfrom() defaulting to true would make the code
more complex. Based on the last code you posted, it looks like you'd
have to add 4 or so new tests to decide whether to do the transaction
stuff. This way, you avoid the additional tests. This pays off in both
understandability and run-time efficiency (the former much more
important than the latter) because the compiler can optimize away
NoTransactions entirely.
This also localizes concerns better: whether to use transactions or not
*is* part of the insertion policy.
And finally, it does offer some flexibility, at the low low cost of a
little extra template goo, which gets paid for out of other accounts:
efficiency, code simplicity, and proper localization of concerns.
