Changes in generic Sets

One morningIdictionary andThe role and region of idictionary <t> are not found. Thank you! But find the next articleArticle, And I will learn it later!


Model set
There is no doubt that the most typical application of the model is the model set. In. NET 2.0, the model versions of existing collection classes and interfaces are provided. They are located in the system. Collections. Generic namespace.

. Net
2.0 the new fan type set class does not simply add a fan type parameter T to the design of the existing non-fan type set class.
. The design of the new fan type set class fully absorbs the rationality of the existing design and abandons some unreasonable aspects. At the same time, it introduces a new fan type design. Therefore, the design of new fan classes and interfaces should be
More reasonable and effective, but. net
ProgramYou need to take some time to learn about new designs and how different they are from existing ones.CodeCompatibility issues that may occur when porting from a non-fan set to a fan set.

The following is a comparison table between a model set and an existing non-model set (incomplete ):

Non-fan Interface	Fan Interface	Non-fan type	ModelClass
Ienumerator	Ienumerator <t>	Arraylist	List <t>
Ienumerable	Ienumerable <t>	Stack	Stack <t>
Icollection	Icollection <t>	Queue	Queue <t>
Ilist	Ilist <t>	Dictionaryentry	Keyvaluepair <K, V>
Idictionary	Idictionary <t>	Hashtable	Dictionary <K, V>
Icomparable	Icomparable <t>	Comparer	Comparer <t>
Icomparer	Icomparer <t>

Yes
as you can see, the name of the partial category has been modified. For example, the arraylist is now changed to list , and the hashtable is changed to
dictionary , change dictionaryentry to keyvaluepair
. This naming method is more reasonable (because ilist is an interface, and list is the corresponding class; similarly,
idictionary is an interface, dictionary is the corresponding class.
keyvaluepair is obviously easier to understand and remember than dictionaryentry
), however, programmers who are used to naming them may feel a little confused at the beginning.

As mentioned earlier, the new model set interface/class has a major design change compared with the previous non-model version. Let's take a look at these changes.

ienumerator
ienumerator/ienumerator
this interface allows you to traverse a set. net traversal statement of the programming language , such as the C # foreach
statement. User code usually does not directly use this interface. Ienumerator Removes the reset
method from the non-standard version ienumerator. This may be due to the following considerations: the
ienumerator interface is mainly designed to support statements such as foreach
, where the reset method is not used. Removing the reset method simplifies the design and reduces the difficulty of implementing this interface. If the caller needs a function similar to reset
, he can obtain an enumerator again (for example, by calling the getenumerator method ).
C #2.0 iterators
provides an automatic generation of enumerators. The Compiler automatically implements the ienumerator interface and ienumerator
interface for the specified class. The implementation of the reset method of the ienumerator interface simply throws the system. notsupportedexception
exception. Therefore, it is natural and reasonable to remove the reset method in the design of ienumerator .

icollection
icollection
the interface design is significantly different from the non-fan version icollection. The icollection interface was originally designed to support copying collection elements (using the count
attribute and copyto method) and synchronous access mode (using the issynchronized attribute and syncroot
attribute ). The icollection Design retains the support for Copying set elements, but does not support synchronous access mode, this is because the synchronous access mode of
icollection is confusing and inefficient. Many programmers who have just learned. Net do not understand syncroot at first.
what is syncroot and what is its use. In addition, in terms of performance and logic, it is up to the caller to decide when to lock the set, rather than the implementer. In general, issynchronized
and syncroot are not ideal designs. Therefore, the icollection does not have the issynchronized attribute and the
syncroot attribute.
In addition, icollection adds new attributes and methods to make the icollection interface more useful. These attributes and methods are actually transplanted from the common attributes and methods of ilist and idictionary, including:
isreadonly, used to determine whether the set is read-only.
Add/Remove/clear: used to manage collection elements. These methods are effective for the list and dictionary.
contains: used to determine whether the set contains the specified value.
In addition to
, an API similar to ireadonlycollection
may be meaningful for scenarios where you do not need to change the collection, it only needs to support the Count attribute, copyto method, and contains
method. However, Microsoft did not adopt such a design. The main reason is to make the basic set interface as simple and easy as possible. Microsoft recommends that programmers define such an interface as needed.

ilist and list
As mentioned earlier, ilist compared with ilist, the general attributes and methods are transplanted into icollection , leaving only the attributes and methods that are effective for the list based on index access.
List
compared with arraylist, the design has also been greatly changed. The primary consideration for making these changes is performance, because dynamic arrays are one of the most basic data structures used by. Net
Programs. Their performance affects the global performance of applications. For example, in the past, the default capacity of arraylist was 16, and the default capacity of
List was 4, which can minimize the working set of the application. In addition, the list
method is not a virtual method (the arraylist method is a virtual method), so that function inline can be used to improve performance (virtual functions cannot be inline ). List
does not support the synchronized synchronous access mode.
List An important feature added to arraylist is support for functional programming. We will introduce this new feature in the functional programming section.

idictionary and dictionary
idictionary V> and dictionary a major change from a non-fan version is the processing logic of the indexer when the specified key does not exist. For
idictionary and hashtable, the storage type of values is object. If the key does not exist, the indexer returns NULL, if the key exists and the corresponding value is
null,
null is also returned (the designer may think that the caller generally cares about whether the value is valid, rather than distinguishing between the two cases ). However, for the fan version, because the stored value type may be,
null cannot be returned as an identifier that does not exist for the key. Therefore, if the specified key does not exist, the indexer of idictionary and dictionary
throws a keynotfoundexception
exception. This causes Source Code incompatibility. That is to say, the following code cannot be transplanted when the value type is stored, it must be rewritten (for example, use the containskey
method to determine whether the specified key exists and then access it; or use the trygetvalue method that does not throw an exception ):
hashtable map = ...;
If (Map ["S1"] = NULL) {// if it is a fan version, an exception is thrown instead of null is returned.
...
}< br>
This
problem reflects that the designer did not consider very well when designing the hashtable class initially. He used the magic value.
null, it can be the case that the key does not exist, or that the key exists and the value is null, which is not true for the model. In addition, from the perspective of design by
contract
, it is natural to throw an exception when the specified key value does not exist (it has nothing to do with whether the model is used ), just as if the array is out of bounds. It is estimated that the original designer used
null rather than Exception Handling mainly from the perspective of performance.

Icomparable <t>, icomparer <t> and comparer <t>
This
Several Interfaces/classes are used for comparison and sorting. Compared with icomparable, icomparable adds equals
Method, of course, to minimize boxing (for Value Type classes ). Compared with icomparer
Equals method, and added the gethashcode
Method. It seems that the comparison is not quite relevant, but in fact, for strings, the comparison is closely related to the hash value. In the previous non-Fan Design, icomparer needs to be used at the same time
And ihashcodeprovider interfaces, such as the hashtable constructor:

Public hashtable (ihashcodeprovider HCP, icomparer comparer );

Its
The ihashcodeprovider and icomparer parameters must match (for example
Invariantcultureignorecase). Otherwise, the result is incorrect. In order to allow programmers to quickly compile the correct code
Icomparer <t> integrates the comparison and hash code generation functions. For example, the constructor of dictionary <K, V>:

Public Dictionary (icomparer <K, V> comparer );

Comparer <K, V> provides the default Implementation of icomparer <K, V>. We recommend that you use comparer <K, V> instead of other methods for comparison and sorting.
Another
. NET 2.0 adds a new string comparison class-stringcomparer, which is located in the system namespace. Stringcomparer
It is not a fan class, but it implements icomparer <string>
Interface, which is useful for strings that require case-insensitive. For example, the following code creates a case-insensitive dictionary:

Dictionary <string, int> dict = new dictionary <string, int> (stringcomparer. invariantcultureignorecase );
Dict ["test"] = 10;
Int n = dict ["test"];

 

 

 

Auto: http://blog.csdn.net/codes/archive/2006/04/10/657375.aspx