Re: Runtime optional interface
SasQ wrote:
[..]
I mean the following is IMO stupid:
SomeClass someObject;
int error = someObject.doSomethingOptional();
if (error) ...;
else ...;
because someObject know BEFORE the user calls doSomethingOptional()
if the optional functionality is available or not. So, if it
knows that it's unavailable, but still allows the user to
call doSomethingOptional() well knowing it'll fail and,
after that, telling the user that HE has made an error,
for me it's very stupid :P Because it's not the user who
made an error, but the class's designer, who allowed the
user to call the optional functionality which sure will fail.
OK, take it one step at a time. What do you call "a call", and
how can it be "disallowed"?
SomeClass &someObject = getObjectFromSomewhere();
if (someObject.hasOptionalInterface()) {
int error = someObject.doSomethingOptional();
}
else {
std::cerr << "there is no optional interface\n";
}
Is that what you're envisioning? <shrug> This still _requires_
the member function 'doSomethingOptional' to be _defined_ although
it is not going to be called provided that 'hasOptionalInterface'
is reliable.
So, 'doSomethingOptional' can be just a virtual function that
does NOTHING in 'SomeClass' (or even declared pure), but should
it actually be an instance of some derived class, it will be
called and it will do something. That's polymorphism in action.
So I'm searching for a way to allow the user to call that
optional functionality only when it's really available
and disallow it totally if it's not available.
class SomeClass { // will have some classes derived from it
public:
virtual ~SomeClass() {}
virtual bool hasOptionalInterface() const { return false; }
virtual int doSomethingOptional() = 0;
};
Now, derive the real class from it, provide (potentially empty)
implementation of 'doSomethingOptional' (if you want to be able
to create an instance of that class), and only if it's truly
capable of that "optional" stuff, override 'hasOptionalInterface'
and return 'true'.
[..]
Well, you mentioned polymorphism, that's a very good
solution for that. Why can't you go with polymorphism?
Because I don't know how to apply it in this particular
case. It's rather a design problem.
Yes. And you're probably approaching your design from the wrong
end. You need to become your user. Define the interface you're
going to be calling. Define the ways your class[es] is/are going
to be used. Don't start with "how do I implement something I do
not yet know".
Perhaps you should explain from the "user"s point of
view what it means to have "optional" functionality.
How does the "user" take advantage of the "optionality"
of the interface?
I'm designing a class being an abstraction of a graphical
screen for a game. The optional functionality is the
window manager [yes, on systems other than Windows it's
possible to play the game in a system without WM available].
If the WM is available, [..]
I think it cannot be done with polymorphism, because
if the WM is available, the user should have some way
to get know about it, and then he should have the
window manipulation functionality available.
*Everything* can be done with polymorphism.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask