interface's IID after it's publish is plain wrong. Anyway, this
question. If one stays away from Automation, lots of issues
A2 : A1 is an approach that could be taken to extend interface. It is a
bit more complex then that (look up interface/library versions rules),
however
imagine that in release 1.0.0.0 you introduce interface A1, so you
clients know exactly how to bind/call it. Than in release 1.0.0.1 you
decide you need to add a function, one way to do it is to derive A2 from
A1, so you old client can still use A1 that they know about and your new
clients can use A2.
There is a lot of trickery associated with interface extensions in COM,
like substitution of interface UUID (A2 takes uuidof(A1) and A1 takes
new UUID) in subsequent releases to accommodate easy recompilation or
playing with fire and installing 2 libraries with different versions(at
one time Microsoft actually recommended that believe it or not) etc.
"anand" <anand.chugh@gmail.com> wrote in message
news:1176827144.235454.322150@l77g2000hsb.googlegroups.com...
On Apr 17, 7:57 pm, "catharticmomentuse...@yahoo.co.uk"
<catharticmomentuse...@yahoo.co.uk> wrote:
It depends a lot on the problem you are trying to solve.
What are the interfaces trying to achieve? If there an "Is-a"
relationship then inheritance maybe a good solution.
Would it be reasonable to have a client that implemented the methods
of A2 without implementing A? If so then you shouldn't use inheritance
(since any implementation of A2 would be forced to include all the
methods from A).
Yeah that depends on lots of stuff, but what would be good design
approach to make components extensible for future??