“Head First Design Pattern – Chinese version of” reading notes – factory pattern (V)
|
Complete a short survey and get free Brand Name samples from QualityHealth.com! |
Give us today is this: the factory pattern.
We create an object in the code, we will naturally think of new. In fact, in addition to new accidents, we have many ways to create objects. Do not say a complex pattern, say a simple syntax, in fact. NET framework, there are the following methods. According to the type of object you need to create, dynamically created objects.
Activator.CreateInstance
We’ve already talked about by a principle:
For interface programming, not for programming.
Obviously using the new object is created for the implementation of a program, new behind the need for a concrete class, an interface does not allow you or the new abstract class. Including the use Activator.CreateInstance can not create the interface or abstract class.
That is not to say the future can not or will not use new, and have to use other way?
Is not, and also to analyze the circumstances, not to generalize, in the back will give some simple criteria, in conjunction with more specific design decision.
Many times we will encounter the following code:
Code
string userType = “”;
if (userType == “admin”)
{/ / Create the administrator
}
else if (userType == “supervisor”)
{/ / Create a super administrator
}
else if (userType == “coommon”)
{
/ / Create a regular user
}
If the user types after the increase, not only to create a user type entities, but also need to open the code to create users, followed by an if. . . else. . . .
If this code does not package, even more trouble, scattered throughout the project, each place must be open, ctrl c, ctrl v. Endless nightmare began.
Become a problem for the maintenance of the back, and in violation of the principle:
OCP principle, increase the opening up of the modified closed.
The principle of first use of this code change package to do some abstract, changes in the above paragraph is obviously more places, other code may be realistic to create a user name and the like. Into a method, then the user type is defined as enum type, reducing input error caused because the caller error.
Code
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace BeautyCode.DesignPattern.Head.First.Factory
{
public enum UserType
{
Admin,
Supervisor,
Common
}
public abstract class User
{
public virtual UserType UserType
{
get;
protected set;
}
public User (UserType userType)
{
UserType = userType;
}
public virtual string Username
{
get;
set;
}
public virtual int Age
{
get;
set;
}
public virtual void DisplayName ()
{
Console.WriteLine (“my name is {0}, i’m {1} years old.”, Username, Age);
}
}
public class AdminUser: User
{
public AdminUser ()
: Base (UserType.Admin)
{}
}
public class CommonUser: User
{
public CommonUser ()
: Base (UserType.Common)
{}
}
public class SupervisorUser: User
{
public SupervisorUser ()
: Base (UserType.Supervisor)
{
}
}
}
Code
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace BeautyCode.DesignPattern.Head.First.Factory
{
public class UserFactory
{
public static User CreateSingleUser (UserType userType)
{
User user = null;
switch (userType)
{
case UserType.Admin:
user = new AdminUser ();
break;
case UserType.Common:
user = new CommonUser ();
break;
case UserType.Supervisor:
user = new SupervisorUser ();
break;
default:
break;
}
return user;
}
}
}
Calling code
Head.First.Factory.User user = Head.First.Factory.UserFactory.CreateSingleUser (Head.First.Factory.UserType.Admin);
After the addition of new types of users do not need to change in various places, as long as a new type of entity, and then open the factory method, modify, click on it.
There is no better?
Can only increase a user type entity classes?
The answer is: can
Changed a bit factory method, the use of generics and Activator
public static T CreateSingleUser2
{
T user = null;
user = Activator.CreateInstance
return user;
}
Modify the caller’s code
Head.First.Factory.User user1 = Head.First.Factory.UserFactory.CreateSingleUser2
There is no better?
Look forward to your participation in the discussion! ! ! !
In fact, I do not count as a real sense that the factory pattern, at most, be regarded as simple plants, which I’ll add some better examples.
Thank you for the patience to read this Notes.
Definition
Factory pattern: defines a pretext for creating an object, but an instance of the subclasses decide which one of the class. Factory method to instantiate the class to be postponed until the child class.
The above description refers to “sub-category of decisions,” the decision, hoping not to wrong interpretation, not a pattern to allow sub-classes themselves to make decisions at run time, but to the creator in the preparation of class, do not need to know the actual creation of the class which one. Caller to choose which class is, naturally, decided to actually create the object.
Sorry, the comment form is closed at this time.


Comments
No comments yet.