Re: Runtime optional interface
SasQ wrote:
Is it possible to write a class with some of its
public interface being optional and dependant of
the runtime circumstances?
No. Class interface is a compile-time thing and it cannot
be optional. Class _functionality_ (behaviour) can change
depending on some conditions, and for that a simple 'if'
statement is often enough:
class TellSeason {
public:
void doTell() {
// get current date
if (month == January
|| month == February
|| month == December)
std::cout << "winter";
else
std::cout << "not winter";
}
};
In the "Object oriented design heuristics" book,
chaoter 5.18 Arthur J. Riel has mentioned the same
problem, but he hadn't shown any good solution.
Maybe because there isn't any...
He wrote that there are two solutions:
1. Putting the optional interface in an inherited class.
<shrug> ...and what? If a pointer/reference to the base
class is going to be used, the interface has to still
be _declared_ in the base. It's not optional.
2. Making the optional obiect contained by reference.
Solution 2 is not convenient for me, because the only
way to return the obiect or nothing is returning the
pointer. So if the optional functionality isn't available,
I'll have to return a null pointer, which may bring to
program crash if the user won't check that pointer but
use it immediately to access methods of the optional
interface.
To prevent that you need smarter users. And you need to
document your pointer-returning function, especially in
the respect that it returns NULL in case the optional
functionality is unavailable. If the users don't check
the pointer for being NULL, it's their problem, not yours.
Secondly, returning a pointer to that
optional interface could be an opportunity for an
error if the user would delete it after use.
Again, that is usually solved by proper documentation of
your functionality. If the user is not supposed to delete
the pointer, just say so in the documentation.
It may
cause a crash if that interface is a part of the
containing object and is used by it.
The solution 1 isn't any better because it's more
static. At runtime I might create either the base class's
object, or the derived class's object, but still I have
to know which one is constructed to use that optional
functionality.
I'm thinking about some way to achieve this better,
because in my program I have some functionality of a class,
which is optional and I can know if it's available only
by checking that at runtime. But I think that allowing
the user to call this optional interface's methods, and then
rewarding the user with an error, isn't a good solution [though
it's commonly used practice], because the object know well that
the optional interface isn't available BEFORE the user might
call it.
I am not sure what you mean here.
I would to offer that optional functionality for
the user only in the case that functionality is available,
and if not, I would like to not allow him to call it.
You're probably imagining things. C++ is statically typed
language, which means all types' interfaces are known at
compile-time.
Is there any good solution of that problem in C++?
Maybe some design pattern or sth like that?
Well, you mentioned polymorphism, that's a very good solution
for that. Why can't you go with polymorphism?
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?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask