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??