In some parts of Objective C #, I'm really sorry for the term "objective" (I)

I 've been halfway through, but I can't see it in some places. In view of the fame of this book and the legendary sales volume, these places are used for discussion and discussion, it should be helpful for anda who has read this book and has not found these things.

Clause 19: Prefer Defining and Implementing Interfaces to Inheritance. This clause instructs us to define and implement interfaces as much as possible, rather than using inheritance.
In fact, abstract classes have the characteristics that some interfaces cannot provide.
1. The interface only provides the behavior provided by the implementation class, but does not provide the specification of these behaviors. For example, a modem interface includes dialing, sending data, receiving data, and hanging up, but there is no way to define that before sending data, you must dial up first, the dialing must be successful. However, different abstract classes can define them.
2. Add a function to the abstract class. Its derived class automatically has these functions; this is obviously not implemented through the interface. The consequence of adding a feature to the interface is that all implementation classes have to be rewritten and re-compiled.
In actual projects, we have encountered such a headache. Therefore, the general practice is to provide an interface and then provide an abstract class that implements this interface. A derived class is generally derived from an abstract class, rather than directly implementing an interface.

OK. Now let's take a look at the inverse example mentioned in <tive C #> proving that an interface is used instead of an abstract class:

Public void PrintCollection (IEnumerable collection)
{
Foreach (object o in collection)
Console. WriteLine ("Collection contains {0 }",
O. ToString ());
}

Public void PrintCollection (CollectionBase collection)
{
Foreach (object o in collection)
Console. WriteLine ("Collection contains {0 }",
O. ToString ());
}

The book says
"The second method is far less reusable. It cannot be usedArrays,ArrayLists,DataTables,Hashtables,ImageLists, Or sort other collection classes. coding the method using interfaces as its parameter types is far more generic and far easier to reuse. "In general, it means that the second method has poor availability and cannot be used, for example, Arrays, ArrayLists, and DataTables. It is very convenient to use the first method for parameters.
Now the question is: who will write the code like this?As a parameter of a method, it may have some restrictions, such as the PrintCollection mentioned above. The only restriction on the implementation of this method is that it must implement the IEnumerable interface. As long as the entry parameter implements this interface, the method can complete the predefined semantics. The second method expands the scope of the limit, and the consequence is reduced availability.
Defining the entry parameter type of a method is a very important principle: Minimal restriction.
This principle applies to the definition of generic classes and generic methods.

The following examples make exactly the same mistakes.

It's time to eat, and the rest will be fooled later. Pai_^

-For more information, see supplement.