Chương 7: Working with Interfaces pptx

In addition to examining a number of predefined .NET interface types, you will also learn how to make use of custom interfaces to build an ad hoc event architecture.”  Interfaces Define

Chapter 7 Working with

“In this chapter you will learn how to define types that support multiple behaviors, how to discover these behaviors at runtime, and how to selectively hide particular behaviors using explicit interface implementation In addition to examining a number of predefined NET interface types, you will also learn how to make use of custom interfaces to build an ad hoc event architecture.”

 Interfaces Define Types

 Defining Interfaces

 Implementing Interfaces

 Interface Member Matching Rules

 Explicit Interface Implementation with Value Types

 Versioning Considerations

 Choosing Between Interfaces and Classes

 7.4 Interface Member Matching Rules

 7.5 Explicit Interface Implementation with Value Types

 7.6 Versioning Considerations

 7.7 Contracts

 7.8 Choosing Between Interfaces and Classes

3

7.1 Interfaces Define Types

 An interface declaration defines a reference type

 Within variables of this type, you can store a reference to an

object that implements the contract of the interface type

 Example: declare interface IUIControl

public interface IUIControl

This interface defines a contract,

which states that any type that implements this interface must implement the Paint() method.

 7.4 Interface Member Matching Rules

 7.5 Explicit Interface Implementation with Value Types

 7.6 Versioning Considerations

 7.7 Contracts

 7.8 Choosing Between Interfaces and Classes

5

7.2 Defining Interfaces

 What is an Interface?

 Defines the signatures for a set of public members that

will be available through an object instance

 Classes provide implementation details

 Classes may implement multiple interfaces

Why use Interfaces?

 Ensure consistency in similar classes

 Classic example: data access

 Allow client applications to write generic code against an interface

 Implementation can be completely with minimum carnage on the client

 Remember: code to the interface – not the

implementation!

7

7.2 Defining Interfaces

 What Can Be in an Interface?

 Interface = purely abstract class; only signatures, no

implementation

 May contain methods, properties, indexers and events (no

fields, constants, constructors, destructors, operators, nested types)

 Interface members are implicitly public abstract (virtual)

 Interface members must not be static

public delegate void DBEvent( IMyDatabase sender );

public interface IMyDatabase : ISerializable, IDisposable

{

void Insert( object element ); //method int Count { get; } //property object this[ int index ] { get; set; } //indexer event DBEvent dbChanged; //event

}

7.2 Defining Interfaces

 Interface Inheritance and Member Hiding

 Interfaces support multiple inheritance from other interfaces in the syntactic sense

must implement the union of all the

methods declared in the interfaces it

directly implements, plus the interfaces those interfaces implement recursively

7.2 Defining Interfaces

 Interface Inheritance and Member Hiding

 Sometimes, you need to declare a method in an interface that hides a method in an inherited interface You must use the new

keyword if you want to keep the compiler from complaining about it with a warning

 Eg When the IEditBox interface declares the Paint method

using the new keyword, it is said to hide the Paint method declared in IUIControl

Use the new keyword

to declare a Paint method whose signature is exactly that of the one in IUIControl

In all calls to the Paint method in the

Main method, it always boils down to

a call on ComboBox.Paint

Because the set of required methods that ComboBox must implement are merged together into one set.

11

 7.1 Interfaces Define Types

 7.2 Defining Interfaces

 7.3 Implementing Interfaces

 7.4 Interface Member Matching Rules

 7.5 Explicit Interface Implementation with Value Types

 7.6 Versioning Considerations

 7.7 Contracts

 7.8 Choosing Between Interfaces and Classes

7.3 Implementing Interfaces

 There are 2 way for implementing interfaces

 Implicit implementations (default): The method

implementations are part of the public contract of the class but also implement the interface implicitly

 Explicit implementations: the method implementations are

private to the implementing class and don’t become part of the public interface Explicit implementation provides some

flexibility, especially when implementing two interfaces that have methods with the same name in them

13

7.3.1 Implicit Interface Implementation

 When a concrete type implements the methods in

inherited interfaces, and those methods are marked

public , it’s known as implicit interface implementation.

public interface IUIControl

}

VALID

7.3.2 Explicit Interface Implementation

 When you implement interface methods explicitly, not only do you add the interface name followed by a dot before the method name, but you also remove the access modifier This keeps it from being in the public contract for ComboBox

15

public class ComboBox : IEditBox, IDropList

{

void IEditBox Paint()

{ Console WriteLine( "ComboBox.IEditBox.Paint()");

}

void IUIControl Paint()

{ Console WriteLine( "ComboBox.IUIControl.Paint()");

public void Paint() { }

public void Show() { }

public void SelectText() { }

public void ShowList() { }

static void Main() {

FancyComboBox cb = new FancyComboBox();

public void Paint() { Console.WriteLine( "ComboBox.Paint()" ); }

public void Show() { }

public void SelectText() { }

public void ShowList() { }

public class EntryPoint

{

static void Main() {

FancyComboBox cb = new FancyComboBox();

public virtual void Paint() { Console.WriteLine( "ComboBox.Paint()" ); }

public void Show() { }

public void SelectText() { }

public void ShowList() { }

7.3.4 Beware of Side Effects of Value Types Implementing Interfaces

 Value types can implement interfaces: make side effect

 If you cast a value type to an interface type, you’ll incur a boxing penalty

 Even worse, if you modify the value via the interface reference, you’re modifying the boxed copy and not the original

19

 7.1 Interfaces Define Types

 7.2 Defining Interfaces

 7.3 Implementing Interfaces

 7.4 Interface Member Matching Rules

 7.5 Explicit Interface Implementation with Value Types

 7.6 Versioning Considerations

 7.7 Contracts

 7.8 Choosing Between Interfaces and Classes

7.4 Interface Member Matching Rules

 The interface member matching rules for C# are pretty straightforward and boil down to some simple rules.

 The rules of the CLR: To find the implementation for

SomeMethod on ISomeInterface, start at the bottom of the hierarchy and search for the first type that implements the interface in question

 The C# method-matching rules: when you walk up the hierarchy, you short-circuit the search once you find a method at a

particular level

21

SomeValue val1 = new SomeValue(1);

SomeValue val2 = new SomeValue(2);

in the form of a reference

to System.Object

CompareTo method accepts general type

First, since CompareTo takes an object reference, val2must be boxed at the point of the method call.

Need to cast the val1 value into an IComparable interface, which

would incur a boxing penalty But once you’re inside the CompareTomethod, the boxing nightmare is still not over

SomeValue val1 = new SomeValue(1);

SomeValue val2 = new SomeValue(2);

method

There is absolutely no boxing in the call to CompareTo That’s because the compiler picks the one with the best match for the type.

23

 7.1 Interfaces Define Types

 7.2 Defining Interfaces

 7.3 Implementing Interfaces

 7.4 Interface Member Matching Rules

 7.5 Explicit Interface Implementation with Value Types

 7.6 Versioning Considerations

 7.7 Contracts

 7.8 Choosing Between Interfaces and Classes

7.6 Versioning Considerations

 Consider interface as contract, or standard

 Standards normally have version numbers attached to them, and when they are revised, the version number is incremented

 For new revisions of your interface, you could simply give it a new name - the key point being that you never change the original interface

 In reality, if your interface definitions live within a versioned

assembly, you may define a newer version of the same interface, even with the same name, in an assembly with the same name but with a new version number The assembly loader will resolve and load the proper assembly at run-time

25

 7.1 Interfaces Define Types

 7.2 Defining Interfaces

 7.3 Implementing Interfaces

 7.4 Interface Member Matching Rules

 7.5 Explicit Interface Implementation with Value Types

 7.6 Versioning Considerations

 7.7 Contracts

 7.8 Choosing Between Interfaces and Classes

7.7 Contracts

 A programming contract is no different than any other contract.

 You usually define a contract to facilitate communication

between two types in your design

 For example, suppose you have a virtual zoo with some

animals An instance of your ZooKeeper needs a way to communicate to the collection of these ZooDweller objects that

they should fly to a specific location However, not all animals can fly, so clearly not all of the types in the zoo can support this flying contract.

27

public sealed class Zoo

{

private static Zoo theInstance = new Zoo();

public static Zoo GetInstance()

creatures = new Collection<ZooDweller>();

zooKeeper = new ZooKeeper();

private ZooKeeper zooKeeper;

private Collection<ZooDweller> creatures;

7.7.2 Interface Contracts

 Use interface for defining the contract

 Ifly for flying contract

public interface IFly

 7.4 Interface Member Matching Rules

 7.5 Explicit Interface Implementation with Value Types

 7.6 Versioning Considerations

 7.7 Contracts

 7.8 Choosing Between Interfaces and Classes

31

7.8 Choosing Between

Interfaces and Classes

 Rules

 If modeling an is-a relationship, use a class: If it makes sense to

name your contract with a noun, then you should probably model it with a class

 If modeling an IMPLEMENTS relationship, use an interface: If it

makes sense to name your contract with an adjective, as if it is a quality, then you should probably model it as an interface

 Consider wrapping up your interface and abstract class

declarations in a separate assembly: Implementations in other assemblies can then reference this separate assembly

 If possible, prefer classes over interfaces: This can be helpful for the sake of extensibility

Summary

model a well-defined, versioned contract using an interface

implement interfaces, we also described the process that the C# compiler follows when matching up interface methods to implementations in the implementing class.

types and value types—specifically, how expensive boxing operations can cause you pain when using interfaces on

value types.

use of interfaces and classes when modeling contracts

between types in your design.

33

pub.