Unit 6-Iunknown & Interfaces

7/30/2019 Unit 6-Iunknown & Interfaces

1/12

Copyright - IT Engg Portal www.itportal.in

IUnknown

This interface enables clients to get pointers to other interfaces on a specified object throughthe IUnknown::QueryInterface method, and manage the existence of the object throughthe IUnknown::AddRefand IUnknown::Release methods. All other COM interfaces are inheriteddirectly or indirectly, fromIUnknown. Therefore, the three methods in IUnknown are the firstentries in the vtable for every interface.

MethodsThe following table shows the methods for this interface in alphabetical order.

Method Description

IUnknown::AddRef Increments the reference count for an interface on an object. Itshould be called for every new copy of a pointer to an interface ona specified object.

IUnknown::QueryInterface Returns a pointer to a specified interface on an object to which aclient currently holds an interface pointer. This method mustcall IUnknown::AddRefon the pointer it returns.

IUnknown::Release Decrements the reference count for the calling interface on aobject. If the reference count on the object falls to zero, the objectis freed from memory.

IUnknown::AddRef

This method increments the reference count for an interface on an object. It should be called for everynew copy of a pointer to an interface on a specified object.

ULONG AddRef(void);Parameters

None.

Return Values

Returns an integer from 1 to n, the value of the new reference count. This information is meant to beused for diagnostic/testing purposes only, because, in certain situations, the value may be unstable.

Remarks

Objects use a reference counting mechanism to ensure that the lifetime of the object includes thelifetime of references to it. You use IUnknown::AddRefto stabilize a copy of an interface pointer. I

can also be called when the life of a cloned pointer must extend beyond the lifetime of the originapointer. The cloned pointer must be released by calling the IUnknown::Release method.Objects must be able to maintain (231) 1 outstanding pointer references. Therefore, the internareference counter that IUnknown::AddRefmaintains must be a 32-bit unsigned integer.
http://technet.microsoft.com/en-us/query/ms890661http://technet.microsoft.com/en-us/query/ms890658http://technet.microsoft.com/en-us/query/ms890669http://technet.microsoft.com/en-us/query/ms890658http://technet.microsoft.com/en-us/query/ms890658http://technet.microsoft.com/en-us/query/ms890661http://technet.microsoft.com/en-us/query/ms890661http://technet.microsoft.com/en-us/query/ms890669http://technet.microsoft.com/en-us/query/ms890669http://technet.microsoft.com/en-us/query/ms890669http://technet.microsoft.com/en-us/query/ms890669http://technet.microsoft.com/en-us/query/ms890669http://technet.microsoft.com/en-us/query/ms890661http://technet.microsoft.com/en-us/query/ms890658http://technet.microsoft.com/en-us/query/ms890669http://technet.microsoft.com/en-us/query/ms890658http://technet.microsoft.com/en-us/query/ms890661


2/12


IUnknown::QueryInterface

This method returns a pointer to a specified interface on an object to which a client currently holds aninterface pointer. This method must call theIUnknown::AddRefmethod on the pointer it returns.

HRESULT QueryInterface( REFIID iid, void** ppvObject );

Parameters

iid[in] Identifier of the interface being requested.

ppvObject[out] Address of the pointer variable that receives the interface pointer requested in riid. Uponsuccessful return, *ppvObjectcontains the requested interface pointer to the object. If theobject does not support the interface specified in iid, *ppvObjectis set to NULL.

Return Values

S_OK indicates that the interface is supported. E_NOINTERFACE indicates that the interface is notsupported.

Remarks

The QueryInterface method gives a client access to other interfaces on an object.

For any one object, a specific query for the IUnknown interface on any of the object's interfaces mustalways return the same pointer value. This allows a client to determine whether two pointers point tothe same component by calling QueryInterface on both and comparing the results. It is specificallynot the case that queries for interfaces (even the same interface through the same pointer) mustreturn the same pointer value.There are four Requirements for implementations ofQueryInterface (In these cases, "must

succeed" means "must succeed barring catastrophic failure."):

The set of interfaces accessible on an object through IUnknown::QueryInterface must be staticnot dynamic. This means that if a call to QueryInterfacefor a pointer to a specified interfacesucceeds the first time, it must succeed again, and if it fails the first time, it must fail on alsubsequent queries.

It must be symmetric if a client holds a pointer to an interface on an object, and queries for thatinterface, the call must succeed.

It must be reflexive if a client holding a pointer to one interface queries successfully for another, aquery through the obtained pointer for the first interface must succeed.

It must be transitive if a client holding a pointer to one interface queries successfully for a secondand through that pointer queries successfully for a third interface, a query for the first interfacethrough the pointer for the third interface must succeed.

IUnknown::Release

This method decrements the reference count for the calling interface on a object. If the referencecount on the object falls to zero, the object is freed from memory.
http://technet.microsoft.com/en-us/query/ms890658http://technet.microsoft.com/en-us/query/ms890652http://technet.microsoft.com/en-us/query/ms890652http://technet.microsoft.com/en-us/query/ms890658


3/12


ULONG Release(void);Parameters

None.

Return Values

Returns the resulting value of the reference count, which is used for diagnostic/testing purposes onlyIf you need to know that resources have been freed, use an interface with higher-level semantics.

RemarksIf the IUnknown::AddRefmethod has been called on this object's interface n times and this isthe n+1 call to IUnknown::Release, the implementation ofIUnknown::AddRefmust cause theinterface pointer to free itself. When the released pointer is the only existing reference to an object(whether the object supports single or multiple interfaces), the implementation must free the object.Aggregation of objects restricts the ability to recover interface pointers.

Inheritance and Interfaces

In addition to making complex systems easier to create and modify by encapsulating functionalitywithin the methods and properties of objects, OOP supports class inheritance and the implementationof interfaces as ways of allowing new classes to be safely added to existing systems without requiringchanges to existing code. We'll compare these two approaches to preparing for change, look at wheneach one is appropriate, and discuss a third approach, object composition, which is often the bestchoice of all.

Inheritance Hierarchies

Of all the OOP techniques available in Visual Basic .NET, inheritance is the least familiar toprogrammers coming from Visual Basic 6.0, where inheritance wasn't available. Even the non-Visua

Basic object models that Visual Basic 6.0 programmers were likely to use, such as ADO or the Officelibraries, rarely required an understanding of inheritance.

Inheritance allows you to create a new class that is a variation on an existing (base) class, and tosubstitute the new derived class in any situation that originally called for the old base class. Forexample, if you have a class called SalesOrder, you can create a new derived class calledWebSalesOrder:

Public Class WebSalesOrderInherits SalesOrder

Any existing methods that take an object of type SalesOrder can remain unchanged and will now bable to handle WebSalesOrder objects as well. If SalesOrder has a Confirm method, you are assuredthat WebSalesOrder will also have a Confirm method. But if Confirm is marked as Overridable in theSalesOrder class, you can create a new Confirm method in the WebSalesOrder class that overrides theoriginal method:

Public Overrides Sub Confirm
http://technet.microsoft.com/en-us/query/ms890658http://technet.microsoft.com/en-us/query/ms890658


4/12


Perhaps the original Confirm method generated a fax to the customer, and the one in WebSalesOrderuses e-mail instead. The important part is that a method originally set up to accept objects of typeSalesOrder will continue to work if you pass it a WebSalesOrder. And if that method calls the Confirmmethod of the object, the customer will get an email rather than a fax. Old code calls new code withoumaking any changes to the old code.

On the other hand, suppose there is a Total method that can work exactly the same for both classesThe derived WebSalesOrder class doesn't need to include any mention of that methodits

implementation will automatically be inherited from the base class, and you'll be able to call the Totamethod for any WebSalesOrder object and have it act just like a SalesOrder object.

Polymorphism

Polymorphism, or substitutability, is one clear benefit of inheritance: any time you create an objecfrom a derived class, you can use that object anywhere you can use an object from the base class. AWebSalesOrder "is a" SalesOrder, and it must be able to do everything a SalesOrder does, even if idoes it in its own distinctive way.

Polymorphism is the key to many of the advantages to OOP, and, as you'll see later in this document

it is not only available when you use inheritance, but also when you use interfaces. Polymorphismallows different kinds of objects that are all able to process a common set of messages to be usedinterchangeably, and to process those messages in their own ways.

Your code to confirm orders doesn't have to know how to perform the confirmation, and it doesn'even have to know what kind of order is being confirmed. It only cares that it can successfully call theConfirm method of the order object it is working with, and it can rely on the object to handle theconfirmation details:

Public Sub ProcessOrder(order As SalesOrder)order.Confirm

When you call the ProcessOrder procedure, you may pass it either a SalesOrder object or aWebSalesOrder object, and they will both work.

Virtual Methods and Properties

Virtuality only comes into play when you override base class methods in derived classes, and it iperhaps the most magical part of inheritance. The magic is that the Microsoft .NET runtimeautomatically finds and runs the most specialized implementation of any method or property that icalled.

For example, calling order.Confirm in the example above reaches down to the Confirm method oWebSalesOrder, where the base SalesOrder.Confirm method was overridden. However, order.Totacalls the Total method of SalesOrder, because no specialized Total method was created inWebSalesOrder.


5/12


Abstract Classes and Methods

An abstract class is one that includes at least one method or property that must be overridden. Foexample, you could have created a SalesOrder class that didn't implement any way of confirming anorder. Knowing that different kinds of orders must be confirmed in different ways, you can specifythat a class derived from SalesOrder must override the Confirm method and provide its ownimplementation.

This means that you couldn't ever create SalesOrder objects. Instead, you would only be able to createobjects using derived classes that filled in the necessary details of how to perform an orderconfirmation. For that reason, the SalesOrder class would be marked MustInherit:

Public MustInherit Class SalesOrderPublic MustOverride Sub Confirm()Public Sub Total()

'Code to calculate a totalEnd Sub

If all the members of a class must be overridden, the class is called a pure abstract class. For example

your SalesOrder class could be just a list of all the methods and properties that need to be overriddenby any derived class. But even if only one member must be overridden, the class will be identified aabstract using the MustInherit attribute.

Type-Checking and Downcasting

Now, what if some kinds of orders need confirmation and some don't? You could use a baseSalesOrder class that doesn't include a Confirm method and only add Confirm to those derived classesthat need it. But this will create a problem: You may want to create a procedure to handle all kinds oorders and confirm those that need confirmation. How would you know which ones to confirm?

You could give the procedure a parameter of type SalesOrder, allowing all types derived fromSalesOrder to be passed in. But then you would need to test for all the different confirmable typesbefore calling the Confirm method. Furthermore, once you found an order type that was confirmableyou would need to downcast from the SalesOrder type, which does not have a Confirm method, to thederived type that does:

Public Sub ProcessOrder(order As SalesOrder)If TypeOf(order) Is WebSalesOrder ThenCType(order, WebSalesOrder).Confirm

ElseIf TypeOf(order) Is EmailSalesOrder ThenCType(order, EmailSalesOrder).Confirm

' and so on

This kind of code is very hard to maintain. It forces you to modify the method any time a new typderived from SalesOrder is added to the system. That kind of coupling between old code and new codeis exactly what you want to avoid.

This would be almost as bad as implementing the confirmation code in this procedure for eachdifferent kind of sales order:


6/12


If TypeOf(order) Is WebSalesOrder Then' Put code here to confirm a WebSalesOrder

ElseIf TypeOf(order) Is EmailSalesOrder Then' Put code here to confirm an EmailSalesOrder

' and so on

That pattern is even worse; not only must you change the procedure for every new type you createyou also no longer have each sales object handling its own confirmation, making it much harder for a

programmer who needs to add a new type of sales order. How would that programmer know all theplaces where new code is needed to handle the new type?

Another approach would be to create an intermediate abstract type called ConfirmableSalesOrderderived from SalesOrder, with a MustOverride method, Confirm. You derive any types that need tohandle confirmation from ConfirmableSalesOrder, and derive any other types directly fromSalesOrder. The procedure now only has to check whether SalesOrder objects passed in were of typeConfirmableSalesOrder, and if so, it could use that type to call the Confirm method:

If TypeOf(order) Is ConfirmableSalesOrder ThenCType(order, ConfirmableSalesOrder).Confirm

The CType downcasting conversion is still required to get to the Confirm method. But then, throughthe magic of virtuality, the call automatically passes down to whichever derived class the order wascreated with and runs the Confirm code defined there.

So, the problem seems to be solved, but this is only a temporary solution. Have you guessed why?Suppose you next need to deal with the fact that some types of orders need a credit check. Some of theorders needing credit checks are also ones that get confirmed, but some aren't. Now you're in trouble.

No Multiple-Inheritance in .NET

You could try creating a CreditCheckableSalesOrder type that derives from SalesOrder. Some ordetypes would derive from ConfirmableSalesOrder, and some from CreditCheckableSalesOrder, butwhat about those that need both confirmation and credit checks? One of the limitations oninheritance in the .NET Framework is that a type can only be derived from one base type.

You can't have order types that derive from both ConfirmableOrder and CreditCheckableOrder. Thismay seem like an arbitrary or misguided limitation, but there are good reasons for it. Multiple-inheritance is supported in C++. However, just about all the other modern object-oriented languagesincluding Java, have chosen not to allow multiple-inheritance. (Some advanced languages, such asEiffel, have attempted to work out the kinks of multiple inheritance, and Eiffel for Microsoft .NETeven provides the appearance of multiple inheritance within Microsoft .NET.)

The biggest problem with multiple-inheritance is that it allows for ambiguity when the compiler needsto find the correct implementation of a virtual method. For example, suppose that Hound and Puppyare both derived from Dog, and then BabyBasset is derived from both Hound and Puppy:


7/12


Figure 1. The problem with multiple-inheritance

Now suppose that Dog has an overridable Bark method. Hound overrides it to sound like a howlPuppy overrides it to sound like a yelp, and BabyBasset doesn't override Bark. If you create aBabyBasset object and call its Bark method, what will you get, a howl or a yelp?

The .NET Framework prevents these kinds of problems by mandating that a derived class can onlyhave a single base class. This limitation also means that every class is ultimately derived from a singlegreat-grand-daddy class, System.Object.

A singly rooted class hierarchy means that any Microsoft .NET object can be handled by a methodthat takes a parameter of type System.Object. One area where this is crucial is garbage collectionbecause the garbage collector that releases memory consumed by inaccessible objects must be able tohandle all kinds of objects.

A more familiar example of the benefits of allowing all objects to be upcast to a common type is evenhandlers:

Public Sub MyEventHandler(By Val sender As _System.Object, By Val e As System.EventArgs)

This handler can be hooked up to events from any object or any combination of objects, because thesender parameter is typed as System.Object, and any Microsoft .NET object can be substituted fothat. If necessary, you can use System.Reflection.GetType() to discover what type of object the senderis.

Creating and Implementing Interfaces

The subtleties concerning inheritance are very interesting, but what are we going to do about our saleorders that need confirmation and/or a credit-check? The answer is to use interfaces.

The problems caused by multiple inheritance of classes result from potential conflicts among thevarious implementations of common methods in the inheritance chain. But suppose you knew thathe classes you were inheriting from were pure abstract classes with no implementation? In that casemultiple-inheritance wouldn't cause any problems because there would be no implementations to


8/12


cause conflicts. This is what interfaces provide: a way to inherit just a set of method and propertyspecifications with no implementation to worry about and no problem inheriting from as manyinterfaces as you need.

Although the phrase "interface inheritance" is often used, the correct term is interfaceimplementation. It is possible for one interface to inherit from another, thereby extending itsmandated set of methods to include those of the interface from which it inherits. However, to useinterfaces in a Visual Basic .NET class, you implementthem rather than inherit them:

Public Interface IConfirmableSub Confirm()

End InterfacePublic Class WebSalesOrder()Inherits SalesOrderImplements IConfirmablePublic Sub Confirm() Implements IConfirmable.Confirm

' Code to confirm a web orderEnd Sub' Other WebSalesOrder code

End Class

(In C#, a colon is used to express both class inheritance and interface implementation. This isprobably why it is conventional to prefix all interface names with an "I". This allows C# programmerto easily distinguish base classes from interfaces.)

You can create some types of sales orders that implement IConfirmable, some that implemenICreditCheckable, and some that do both. To check whether an order is confirmable, you use the samekind of code you would use to check whether or not it was derived from a particular base type and todowncast it to that type:

Public Sub ProcessOrder(order As SalesOrder)If TypeOf(order) Is IConfirmable ThenCType(order, IConfirmable).Confirm

Interface Polymorphism

You can use interfaces to provide the same benefits of polymorphism that are available when usingderived classes. For example, you can pass any object made from a class that implementsIConfirmable to a method that takes a parameter of type IConfirmable:

Public Sub ConfirmOrder(order As IConfirmable)order.Confirm

End Sub

If WebSalesOrder and EmailSalesOrder both implement IConfirmable, you're able to pass either kindof object to the ConfirmOrder method. When it calls order.Confirm, the confirmation code that wasimplemented in the appropriate class will run. This works even if you don't name the class methodConfirm, as long as you mark it as implementing the Confirm method of the IConfirmable interface:


9/12


Public Class WebSalesOrder()Inherits SalesOrderImplements IConfirmablePublic Sub ConfirmWebOrder() _Implements IConfirmable.Confirm' Code to confirm a web order

End Sub

This naming freedom is a useful feature. It comes in handy if your class implements two differeninterfaces that happen to have methods with the same name.

Comparing Class Inheritance and Interface Implementation

The most important technical distinction between creating a derived class and implementing aninterface is that a derived class can only inherit from one base class, but a class can implement anynumber of interfaces.

From a design standpoint, think of inheritance as expressing a specialization hierarchy. IWebSalesOrder "is a" special kind of SalesOrder, you might consider making it a derived class.

However, you need to be very careful that you don't use inheritance when the specialization thadistinguishes a derived class from a base class is a feature that other classes will also need to supportFor adding those kinds of features or capabilities to a class, implementing interfaces will give youmuch greater flexibility.

Inheritance is for Building Frameworks

Designing useful inheritance hierarchies takes careful planning and a clear vision of how thehierarchy will be used. Think of it as a task to be performed by an accomplished software architecwho is creating a framework that will be used by programmers building a variety of applications, no

as a strategy to use when you are simply building a particular application.

The .NET Framework itself includes many examples of inheritance at work, and you will need tocreate derived classes to perform many common programming activities. For example, you can createyour own specialized exception classes derived from ApplicationException to carry customized erroinformation. When you raise custom events, you send information to event handlers by creating acustom class derived from EventArgs. To create a type-specific collection, you'll derive fromCollectionBase. And every time you create a Windows form in Visual Studio .NET, you are derivingfrom the Windows.Forms.Form base class.

You need to be comfortable creating derived classes from base classes provided for you by framework

architects, but be very cautious about creating your own base classes. Be sure that you are expressinga clear specialization hierarchy, and that you have clearly factored out the behaviors that you expecclient programmers to override.

The same caution applies to creating your own interfaces, but you are much less likely to paintyourself into a corner with interfaces than with inheritance, so give them preference if you feel youhave a choice.


10/12


Object Composition

When considering the creation of your own inheritance hierarchies, don't be overly influenced by theappeal of code reuse. That alone is not a good reason to create a derived class.

Instead of using inheritance to allow a new object to make use of code from an existing object, you caninstead use a technique that goes by several different names: composition, containment, aggregationor wrapping. This is a technique that you are likely to have used in Visual Basic 6.0, where

inheritance wasn't an option.

For example, to create a WebSalesOrder class that reuses all the code in the SalesOrder class and thatalso adds some new twists, you declare and create an instance of a SalesOrder object in youWebSalesOrder class. You can publicly expose the internal SalesOrder, or you can keep it private.

Delegation

If SalesOrder has a Total method, your WebSalesOrder can have a Total method that simply calls intothe Total method of the private SalesOrder instance. This technique of passing along method calls (oproperty calls) to an internal object is often called delegation, but don't confuse it with the unrelated

use ofdelegate objects to create callback functions and event handlers in Microsoft .NET. The eventsof your contained objects can be exposed in the wrapper class by declaring the contained object usingthe WithEvents keyword, just as in Visual Basic 6.0.

Combining Composition with Interface Implementation

The primary disadvantage of using object composition and delegation is that you don't automaticallyget polymorphism the way you do with derived classes. If your WebSalesOrder object simply containsa SalesOrder object, rather than being derived from one, then you can't pass a WebSalesOrder objecto a method that has a parameter of type SaleOrder.

You can easily work around this disadvantage by creating an ISalesOrder interface that youWebSalesOrder implements. You have the option of delegating to the methods and properties of thecontained SalesOrder object. Or, as needed, WebSalesOrder can independently implement some ofthe methods and properties in the interface instead of delegating to the SalesOrder object. This issimilar to overriding in derived classes.

By combining object composition and delegation with interface implementation, you get code reuseand polymorphism without the design headaches of inheritance. For this reason, consider this as yourfirst choice when you need to extend or specialize the functionality of classes.

What's Different From Visual Basic 6.0?

In Visual Basic 6.0, every time you create a class module, a hidden interface of the same name isautomatically created for you. Consider the following Visual Basic 6.0 code:

' Visual Basic 6.0 codeDim myObject As MyClassSet myObject = New MyClass


11/12


In this code, the first use of MyClass refers to the hidden interface containing empty methods andproperties, and the second MyClass is the concrete class you wrote that implements those methodsand properties. Visual Basic 6.0 shelters you from having to think about this use of interfaces, whichis essential to the underlying COM plumbing.

The Implements keyword in Visual Basic 6.0 allows you to make explicit use of interfaces and to takeadvantage of the same interface-based polymorphism that is available in Visual Basic .NET. Theimplementing class, however, must use a naming convention that incorporates the name of the

interface:

' Visual Basic 6.0 IConfirmable class modulePublic Sub Confirm()End Sub

' VB6 WebSalesOrder class moduleImplements IConfirmablePrivate Function IConfirmable _Confirm()

' Implementation code here' to confirm the order

End Function

Any Visual Basic 6.0 object implementing IConfirmable in this way can be passed to a procedure thatakes a parameter of type IConfirmable, supporting the same type of polymorphism that interfacesprovide in Visual Basic .NET:

' Visual Basic 6.0 or Visual Basic .NETPublic Sub ConfirmOrder(order As IConfirmable)order.Confirm

End Sub

Although the syntax for working with interfaces is more flexible and less confusing in Visual Basi.NET, the biggest change is support for inheritance. Deriving a new class from an old one and pickingup the functionality of the old class isn't possible in Visual Basic 6.0, so there is also no way tooverride only selected methods.

This is a very significant change, but not because you have a burning need to create your own basclasses and derive from them. The biggest value comes from being able to inherit the same frameworkclasses used by programmers working in C#, C++, or any other Mirosoft .NET language. And if you docreate inheritance-based frameworks yourself in Visual Basic .NET, any other Microsoft .NETprogrammer can use your frameworks. This puts Visual Basic .NET on equal footing with all theMicrosoft .NET languages and breaks down the barriers that have isolated Visual Basic programmersin the past.

Summary

In this document, you learn about the differences between class inheritance and interfaceimplementation. Inheritance supports the creation of hierarchical frameworks of increasinglyspecialized classes that share some code and also add their own customizations. Interfaces allowmultiple unrelated classes to share predictable sets of methods and properties. Both interfaces and


12/12


inheritance provide polymorphism, allowing generic procedures to work with many different kinds oobjects. You also saw how object composition allows you to reuse and extend implementation codewithout inheritance, and how it can be combined with interfaces to support polymorphism. All thesetechniques enable you to create and revise complex software systems by helping you add newfunctionality, with minimal need to dig back into old working code.

Documents

Unit 6-Iunknown & Interfaces