Dependency created by the object

Dependency created by the object

Concerning the dependency philosophy, the most typical violation is the dependency created by the object. Since the establishment of the object-oriented flag, the discussion on Object creation topics has never stopped. Whether it is the factory mode or dependency injection, there is only one core idea: how to better decouple the dependency created by the object. Therefore, in this section, we take object creation as the main line to understand the design trajectory of dependency relationships, this article describes the implementation, features, and differences of general object creation, factory creation, and dependency injection creation methods.

1. Typical Violation

In general, object creation with the new keyword is justified in the. NET world. In section 7.1 of this book, we thoroughly analyzed the role and underlying mechanism of New in object creation. For. Net programmers, object creation with new is a common practice. In most cases, this method has no problem. For example:

Public abstract class animal

{

Public abstract void show ();

}

 

Public class Dog: Animal

{

Public override void show ()

{

Console. writeline ("this is dog .");

}

}

 

Public class Cat: Animal

{

Public override void show ()

{

Console. writeline ("This is Cat .");

}

}

 

Public class normalcreation

{

Public static void main2 ()

{

Animal animal = new dog ();

}

}

For animal objects, the specific dog class is relatively stable in most cases, so such dependency is often harmless. This is also one of the reasons we are used.

However, just as we have come to the conclusion of analyzing abstract and specific concepts in this article, relying on specific concepts does not effectively guarantee their stability. In this example, if a new bird and horse are added to the zoo, the Administrator's management based on the existing system is bound to be unable to adapt to the form, because all the instances created depend on dog. Therefore, the general object creation method is actually a typical violation of the dip principle. The creation of high-level animal relies on the lower-layer dog, and the general dip basic principle is against.

Therefore, dip is not always followed by Oo, and developers only need to properly grasp it. To solve the dependency violation problem of creating objects in the new method, the typical solution is to abstract the created dependency from the specific one. Generally, there are two ways to deal with it: factory mode and dependency injection.

2. Factory Model

The method of object creation in factory mode mainly includes two modes: Abstract Factory mode and factory method mode. This article does not want to discuss the differences and meanings of the two, if you are interested, refer to gof's design patterns: the basis for reusable object-oriented software.

In this article, the perspective is pulled back to the ichannelfactory of WCF and the creation of various channels. In this way, the channel layer design idea in the WCF architecture is used to apply the factory mode to design and expand object creation, to understand the essence and implementation of object creation dependency relief in the application factory mode.

Note:

For more information about the concept of channel in WCF, you only need to regard it as a simple type.

First, let's take a look at the Channel creation process:

Public class factorycreation

{

Public static void main ()

{

Endpointaddress Ea = new endpointaddress ("http://api.anytao.com/userservice ");

Basichttpbinding binding = new basichttpbinding ();

Ichannelfactory <irequestchannel> facotry = binding. buildchannelfactory <irequestchannel> ();

Facotry. open ();

Irequestchannel channel = facotry. createchannel (EA );

Channel. open ();

// Do something continue...

}

}

In this example, the irequestchannel instance is created through the ichannelfactory. Therefore, the focus of focusing on the factory creation is on ichannelfactory and irequestchannel. Essentially, In the WCF channel layer, channelfactory is the factory encapsulation for creating and managing channels. Channel factories are used to create channel instances. All Channel factories must inherit from ichannelfactory, it is defined:

Public interface ichannelfactory <tchannel>: ichannelfactory, icommunicationobject

{

Tchannel createchannel (endpointaddress );

Tchannel createchannel (endpointaddress to, Uri );

}

The tchannel parameter is used to register the type information of the created instance, and then the corresponding object instance is created based on the endpointaddress information. Of course, there is still a lot to consider and learn about the factory model application in WCF. It is impossible to implement a similar design structure in the current space. Drawing on the design concept of WCF, we will make some modifications to the creation of the animal instance to implement the design based on the generic factory model, first, define a template created by an object:

Public interface ianimalfacotry <tanimal>

{

Tanimal create ();

}

Then implement the generic factory method of the template:

Public class animalfacotry <tanimalbase, tanimal>: ianimalfacotry <tanimalbase> where tanimal: tanimalbase, new ()

{

Public tanimalbase create ()

{

Return new tanimal ();

}

}

The type parameter tanimalbase represents the high-level type, while the tanimal parameter represents the underlying type. its contractual relationship is clearly defined in the where constraint, and then is an encapsulation Based on the factory method:

Public class facotrybuilder

{

Public static ianimalfacotry <animal> build (string type)

{

If (type = "dog ")

{

Return new animalfacotry <animal, dog> ();

}

Else if (type = "cat ")

{

Return new animalfacotry <animal, cat> ();

}

 

Return NULL;

}

}

Finally, let's take a look at the factory-based object creation implementation:

Class Program

{

Static void main (string [] ARGs)

{

Ianimalfacotry <animal> factory = facotrybuilder. Build ("cat ");

Animal dog = factory. Create ();

Dog. Show ();

}

}

As you can see, the dependency created by the object has been converted from the specific dependency of the new type to the abstract and high-level dependency. In this example, you can eliminate the IF/else runtime type determination through reflection, thus completely removing this dependency from configurable and flexible customization. This is the great significance of the abstract factory method. In this example, you can fully extend ianimalfacotry to a flexible factory in the form of ianyfactory. You can register any type of txxxbase and TXXX in the type parameter, in this way, more powerful object generators are implemented, but more code and extensions are required. You can think about this.

This article is excerpted from the book ". Net (version 2nd) You must know ".

Book details: http://blog.csdn.net/broadview2006/article/details/6673353