language agnostic - Why should you ever have to care whether an object reference is an interface or a class? -
i seem run discussion of whether or not apply sort of prefix/suffix convention interface type names, typically adding "i" beginning of name.
personally i'm in camp advocates no prefix, that's not question about. rather, it's 1 of arguments hear in discussion:
you can no longer see at-a-glance whether interface or class.
the question pops in head is: apart object creation, why should ever have care whether object reference class or interface?
i've tagged question language agnostic, has been pointed out may not be. contend because while specific language implementation details may interesting, i'd keep on conceptual level. in other words, think that, conceptually, you'd never have care whether object reference typed class or interface i'm not sure, hence question.
this not discussion ides , or don't when visualizing different types; caring type of object necessity when browsing through code (packages/sources/whatever form). nor discussion pros or cons either naming convention. can't seem figure out in scenario, other object creation, care wether or not you're referencing concrete type or interface.
most of time, don't care. here instances can think of would. there several, , vary little bit language. languages don't mind as others.
in case of inversion of control (where passes parameter) don't care if it's interface or object far calling methods etc. when dealing types, can make difference.
in managed languages such .net languages, interfaces can inherit 1 interface, whereas class can inherit 1 class implement many interfaces. order of classes vs interfaces may matter in class or interface declaration. need know which when defining new class or interface.
in delphi / vcl, interfaces reference counted , automatically collected, whereas classes must explicitly freed, lifecyle management on whole affected, not creation.
interfaces may not viable sources class references.
interfaces can cast compatible interfaces, in many languages, cannot cast compatible classes. classes can cast either.
interfaces may passed parameters of type iid, or iunknown, whereas classes cannot (without cast , supporting interface).
an interface's implementation unknown. input , output defined, implementation creates output abstracted. in general, ones attitude may when working class, 1 may know how class works. when working interface, no such assumption should made. in perfect world, might make no difference. in reality, can have affect design.
Comments
Post a Comment