On Dec 16, 4:50 pm, Maxim Yegorushkin<maxim.yegorush...@gmail.com>
wrote:
On 16/12/09 13:50, Michael Mol wrote:
In other words, you've got:
1) A factory that creates objects.
2) Those objects implement an interface, which is currently belongs to
factory class.
3) You'd also like for the factory to check whether the object reference
is valid.
The code exists, and it's been in the field for over a year. What I'd
*like* is an abstracted pass-through to work with existing code.
You can refactor this to simply things.
1) Extract object interface from the factory.
struct SomeObject {
// former SomeFactory::OperateOnObject
virtual ERRCODE Operate(int someArgument) = 0;
virtual ~SomeObject() = 0;
};
Using such object now does not require a factory object, i.e. you can
call Operare() directly on the object.
Which is the type of apparent behavior I'd like. However, the factory
object can't be removed entirely, as it also manages the relationship
of object instances to each other and the system resources they happen
to extract. (A bit of internal behavior I hoped wasn't necessary to
describe in order to ask about intuitive of dereferencing syntax.)
2) Make factory return smart-pointers to SomeObject. The objects it
creates implement SomeObject interface.
typedef boost::shared_ptr<SomeObject> SomeObjectPtr;
class SomeFactory {
public:
SomeObjectPtr createSomeObject();
...
};
Now the factory function returns a smart-pointer. This smart-pointer
takes care of destroying the object when it is no longer used. No manual
object destruction required.
The object represents an abstraction of a system resource, and there
are a lot of operating factors that weigh in on when it's appropriate
to free that system resource. It normally doesn't happen during the
weeks-long run of an application, though it does on occasion.
3) Using a smart-pointer makes the possibility of using an already
destroyed object highly unlikely. Checking whether the object reference
is valid may be not necessary any more.
New usage:
SomeFactory factory;
// later in some function or scope
{
SomeObjectPtr object = factory.createSomeObject();
object->Operate(123);
} // now object goes out of scope and gets destroyed automatically
This looks to be simpler and more intuitive, isn't it?
Because of the pervasive and high-traffic use of the subsystem
OBJHANDLE is part of, and because of the nature of the application,
"highly unlikely" is inevitability, and minimizing risk while meeting
the client's feature desires close to their scheduling desires is the
order of the day. Given the choice between such a large-scale
refactoring and dealing with a new formulation of the code or staying
with a tedious syntax, I'd stay with the tedious syntax.
I understand what you're saying, and for new code design, that would
be fine. However, the current code exists, has been fielded for over a
year, is a core and frequently-trafficked component where that traffic
is fairly sensitive--and it's stable.
That's why my original fielded question laid out two options; Either
can be implemented with few risks to stability, and I was looking for
a discussion regarding of wrapping a handle such that it may be
operated with a more terse syntax.
management. This can well be the interface shown above.
interface and the new one. This allows to gradually evolve to using the
management. Otherwise you may well be better off using plain C.