Question

I have some questions about the affects of using concrete classes and interfaces.

1. Say some chunk of code (call it chunkCode) uses concrete class A. Would I have to re-compile chunkCode if:

   1. I add some new public methods to A? If so, isn’t that a bit stange? After all I still provide the interface chunkCode relies on. (Or do I have to re-compile because chunkCode may never know otherwise that this is true and I haven’t omitted some API)
   2. I add some new private methods to A?
   3. I add a new public field to A?
   4. I add a new private field to A?

2. Factory Design Pattern:
   The main code doesn’t care what the concrete type of the object is. It relies only on the API. But what would you do if there are few methods which are relevant to only one concrete type? This type implements the interface but adds some more public methods? Would you use some if (A is type1) statements (or the like) the main code?

Thanks for any clarification

Answer 1

For your first question the answer is NO for all your points. If it would be that way then backward compatibility would not make any sense. You have to recompile chunkCode only if you brake the API, that is remove some functionality that chunkCode is using, changing calling conventions, modifying number of parameters, these sort of things == breaking changes.

For the second I usually, but only if I really have to, use dynamic_cast in those situations.

Note my answer is valid in the context of C++;I just saw the question is language agnostic(kind of tired at this hour; I’ll remove the answer if it offenses anybody).