Re: Is there any problem with customizing a new interface out of
other interfaces?
On 2010-09-01 11:14, Goran Pusic wrote:
On Aug 31, 9:31 pm, DeMarcus<use_my_alias_h...@hotmail.com> wrote:
Hi,
Let's say I have three interfaces
class IWorker
{
public:
virtual ~IWorker() {}
virtual void work() = 0;
};
class IEnergyConsumer
{
public:
virtual ~IEnergyConsumer() {}
virtual void refuel( int energy ) = 0;
};
class ICloner
{
public:
virtual ~ICloner() {}
virtual ICloner* clone() = 0;
};
Would it be problematic or immoral to create a new pure interface out of
those, like this?
class ICell : public IWorker, public IEnergyConsumer, public ICloner
{
public:
virtual ~ICell() {}
};
Or is it just fine to customize new interfaces out of existing interfaces?
Thanks,
Daniel
PS. I haven't seen it before, that's why I'm asking. If you have any
references to such thing, please let me know.
I'd say what you want goes against interface segregation principle of
SOLID (http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod). I
mean, if you're making interfaces, and even if you need two+
interfaces on one object in a given piece of code, there's nothing
wrong in passing two interface references in, or "dynamic_casting"
from one to another. What you seem to want to do is to separate your
interfaces (for e.g. clarity of design), but also mix them back again
(for e.g. convenience^^^). Sure, you can do it, but it's kinda sour...
^^^ but which brings you back to "massive base class" design smell.
Ok, I agree with you, you have a good point. However, I don't want to
mix them back "for convenience". The reason is rather to put constraints
on entities.
Let's say I want to create a function that can take all kinds of
objects, but with the constraint that they must at least be clonable and
be able to do some work. Is the following still a bad idea?
class IConstrainedObject : public ICloner, public IWorker
{
public:
virtual ~IConstrainedObject() {}
};
void someFunction( IConstrainedObject* object ) { /* ... */ }
(As I write this I see that it will force objects to be clonable and do
some work, which is good, but it will also block objects not inheriting
from IConstrainedObject that actually may implement both ICloner and
IWorker.)
I still agree with your "massive base class design smell", but I also
want some tool to tailor-make interfaces.
There are patterns, like mix-ins and policies to tailor-make
implementations, but aren't there any nice pattern to tailor-make
interfaces as well?