博客园_小AI

[立此存照]Push-up

2012-05-05T06:56:00Z

本文链接

Definition of Refactoring

2012-04-10T14:22:00Z

Long time since my last post, busy with the work these months.

Update here with the definition of the refactoring.

From the classic book: Refactoring by MF:

Refactoring(noum): a change made to the internal structure of the software to make it easier to understand and cheaper to modify without changing its observable behavior.
Refactoring(verb): to restructure software by applying a series of refactorings without changing its observable behavior.

Hopefully, will get back here soon.

本文链接

TypeInitializationExeption

2012-02-10T07:45:00Z

mark here, finish soon.

本文链接

a link for book

2011-12-20T13:25:00Z

http://news.cnblogs.com/n/125826/

本文链接

[review]Design Pattern:State

2011-12-12T14:48:00Z

State

Alter the object's behavior by the changes of its state. And the states are all encapsulated into single object state by state. decouple the state(especially the object's behavior under different states) from the the object itself

When we use this pattern

They are all about the state of the object and dependency on the state, we are highly recommended to use this pattern if below:

The behavior of the object depends on its states so much, the behavior will be changed while the changes of the states
If we got lots of if/else statements to describe different behaviors under different conditions. By the help of this pattern, we can design the each statement as a very concrete state object. If we got lots of if/else statements, our method may be very large, which is not what we expected and is ugly. we should avoid this situationa and try our best to reduce the using so many if/else statements.

Roles in this pattern

Content: This is the very object that depends so much on its states. this object defines the interface that the clients want. and also maintains an instance of the ConcreteState which represents the current state of the Content
State: this is interface designed for the particular behavior depending on the particular state
ConcreteState: a object which represents an particular state and also implements the State interface for the particular bahavior, the amount of the ConcreteState depends on the amount of Content's state.

One more thing for the ConcreteState: which not only implements the particular behavior of the content but also is responsible fot setting the content's state from the current(itself) to the next.

Easy to say but hard to do, a small example below to demonstrate the above:

namespace State
{
public abstract class State
{
public abstract void Handle(Content content);//implement the behavior but also change the state to next
}

public class ConcreteStateA : State
{
public override void Handle(Content content)
{
Console.WriteLine("ConcreteStateA.Handle");//implement the behavior
content.State = new ConcreteStateB();//change the state, the next state of this state is state B
}
}

public class ConcreteStateB : State
{
public override void Handle(Content content)
{
Console.WriteLine("ConcreteStateB.Handle");//implement the behavior
content.State = new ConcreteStateA();////change the state, the next state of this state is state A
}
}
public class Content
{
private State state;

public Content(State state)
{
this.state = state;
}

/// <summary>
/// default constructor is here to set the default state if no special state is asked when initialization
/// </summary>
public Content()
{
this.state = new ConcreteStateA();
}

public State State
{
get { return this.state; }
set { this.state = value; }
}

public void Request()
{
state.Handle(this);
}
}
class Program
{
static void Main(string[] args)
{
Content content = new Content();//use the default constructor
content.Request();
content.Request();
content.Request();
}
}
}

Different hehaviors under different states, the behavior is implemented by the corresponding state which also changes the state from the current to the next.

The content maintains the instance of an state and its behaviors are changed by the changes of its states. But they are decoupled from each other .

The state is self-described.

The one who always maintains the instance of State is the state.

The state is the state which belongs to the Content but not others.

本文链接

[review]Design Pattern:Bridge

2011-12-08T14:29:00Z

Bridge

The book told me that this pattern is dedicated to decouple the abstraction from its implemetation so they can vary by themself without affecting each others.

To be honest, I don't know which one I should call as abstraction and which one as implemetation. I call them two structures designed for different functions. They focus on different situations, but they should work together to get the things done.

There are so many ways for us available to composite two objects and to let them work together. A very frequent way is to use the inheritance mechanism.

But the inheritance has drawbacks with less flexible in some situations. The inherited class depends on its father class so much. It is hard to modify, to extend.

We can use another way to improve this situation with the new machenism called as Composition and Aggregation. Which makes a "Has" structure compared with the inheritance mechanism with the "is-a" structure.

With the new one, the different parts can work independently but also can work together.

Software design is so flexible that there is no a hard way to let us know to choose which one. it is full of trade-offs based on our experiences and the special situations.

Sometimes the inheritance is good but sometimes the composition or the aggregation is better.

The Bridge Pattern is the very structure which uses the Composition structure to design the system. If you draw the UML of this pattern, you can find dramatically that the structure is like a very bridge, which bidges the two different parts(the two ones the book called as Abstraction and Implementation) and helps them communicate with each other and cooperates with each other.

A small example here to show this pattern:

namespace Bridge
{
public abstract class Implementor
{
public abstract void Operation();
}

public class ConcreteImplementorA : Implementor
{
public override void Operation()
{
Console.WriteLine("Operation A");
}
}

public class ConcreteImplementorB : Implementor
{
public override void Operation()
{
Console.WriteLine("Operation B");
}
}

public class Abstraction
{
protected Implementor implementor;

public void SetImplementor(Implementor implementor)
{
this.implementor = implementor;
}

public virtual void Operation()
{
implementor.Operation();
}
}

public class RefinedAbstraction : Abstraction
{
public override void Operation()
{
implementor.Operation();
}

}
class Client
{
static void Main(string[] args)
{
Abstraction ab = new RefinedAbstraction();

ab.SetImplementor(new ConcreteImplementorA());
ab.Operation();

ab.SetImplementor(new ConcreteImplementorB());
ab.Operation();
}
}
}

本文链接

[review]Design Pattern:Iterator

2011-12-07T15:04:00Z

Iterator

A way provided by this pattern lets the client access the aggregate object in turns(one by one) but without exposing the details of the aggregate object.

An iterator are designed in this pattern to enumerate the object.

Auctually. ASP.NET has implemented this pattern with providing two interfaces:

IEnumerator: does not support the generics
IEnumerable: support the generics

Most of time for most of situations they are enough for our program. there is no need for us to do it ourself. But it is ok for us to dig, which can give us more.

The iterator is responsible for enumerating the aggregate object and accesing the inner types of the object. The client just uses the Iterator to MoveNext. to access the First.etc.

If you want a object to be accessed by the index, implement the indexer provied by the C#, and also implement the Iterator(customed or inherent ones), the interator will hold the object and make the enumeration if needed.

Investigating the history is for further understanding of the future.

I made a demo implementing the Iterator pattern, and also supporting the generics, see below:

One more thing, I strongly recommend every one should use the generics supported from the C#2 for security issues for performance issue.

本文链接

[review]Design Pattern:Command

2011-12-06T15:11:00Z

Command

Encapsulate an request into the object. The command holds the receiver, the invoker holds the command.

encapsulate the details, show the interface to the client. the client does not know the exact implemetation .

The client only cares about his request and tells the invoker what his request is, the invoker creates an appropriate command according to the client's request and executes the command.

The command holds the approriate receiver. the receiver's action is executed, the things are done.

Actually this pattern also decouples the appearance from the implemetation. So called DP is nothing but OOD, exactly the experience about how the BIG GUYS use the OOD.

IMO, every software designer and programmer should know all the DP even you don't use some of them. after that you got more than the DP itself. One who learns the PD should compare them together.

I do like this pattern very much. I got more than the pattern itself.

A small demo here to show the above:

namespace Command
{
public class Receiver
{
public void Action()
{
Console.WriteLine("Execute Action");
}
}

public abstract class Command
{
protected Receiver receiver;

public Command(Receiver receiver)
{
this.receiver = receiver;
}

public abstract void Execute();
}

public class ConcreteCommand : Command
{
public ConcreteCommand(Receiver receiver) : base(receiver) { }
public override void Execute()
{
receiver.Action();
}
}

public class Invoker
{
private Command command;

public void SetCommand(Command command)
{
this.command = command;
}

public void ExecuteCommand()
{
this.command.Execute();
}
}

class Client
{
static void Main(string[] args)
{
Receiver r = new Receiver();
Command c = new ConcreteCommand(r);

Invoker i = new Invoker();
i.SetCommand(c);
i.ExecuteCommand();
}
}
}

本文链接

[review]Design Pattern:Builder

2011-12-05T14:49:00Z

Builder

Decouple the appearance from the construct process(algorithm) for a complicated object, the algorithm can be used for so much appearance. for reusing the algorithm, for hiding the details from the client. The appearance can be showed without leaving any parts needed with the help of the unified interface provided by the Director.

When we use this pattern

as i told above.

Roles in this pattern

Builder: define the interface for creating the part of the product
ConcreteBuilder: implement the Builder interface for the very certain product, for the very given appearance. and also provide an interface for retrieve the current product that the current ConcreteBuilder is trying to build
Director:define the interface to create the product by the interface provided by the Builder, the interface design the algorithm about how the product is created and how to use the part of the interface implemented by the ConcreteBuilder, the order how the parts show themself
Product: the one we want to create.

Demo

namespace Builder
{
public class Product
{
List<string> parts = new List<string>();

public void Add(string part)
{
parts.Add(part);
}

public void ShowProduct()
{
foreach (string part in parts)
{
Console.WriteLine(part);
}
}
}

public abstract class Builder
{
public abstract void BuilderA();
public abstract void BuilderB();
public abstract Product GetResult();
}

public class ConcreteBuilder1 : Builder
{
private Product product = new Product();
public override void BuilderA()
{
product.Add("1A");
}

public override void BuilderB()
{
product.Add("1B");
}

public override Product GetResult()
{
return product;
}
}

public class ConcreteBuilder2 : Builder
{
private Product product = new Product();
public override void BuilderA()
{
product.Add("2A");
}

public override void BuilderB()
{
product.Add("2B");
}

public override Product GetResult()
{
return product;
}
}

public class Director
{
public void Construct(Builder builder)
{
builder.BuilderA();
builder.BuilderB();
}
}

public class Client
{
static void Main(string[] args)
{
Director director = new Director();
Builder b1 = new ConcreteBuilder1();
Builder b2 = new ConcreteBuilder2();

director.Construct(b1);
Product p1 = b1.GetResult();
p1.ShowProduct();

director.Construct(b2);
Product p2 = b2.GetResult();
p2.ShowProduct();

Console.Read();
}
}
}

IMO, this pattern can be learnt with the Factory, the Template and the Strategy... They are some kind similar to each other. BUT they are different, it is interesting to differentiate them. and it is also useful to have a better comprehension and understanding for all the pattern and OOP if you dig them together.

本文链接

[review]Design Pattern:Memento

2011-12-01T15:01:00Z

Memento

Memento as its name describes, which is for storing something. for recorving something from it.

We want to capture the type's inner state at a given time and also want to recove it to where it was captured but without jeopardizing the encapsulation without exposing the type's details to the client. The memento pattern makes it happen.

When we use this pattern

for storing the state first and recover the state from where it stored. We can do it with the normal method with a temp variable(instance) of the type and use the getter and setter to finish it. like below:

public class MyClient
{
public void StoreWithTheNormalWay()
{
MyType myType = new MyType();
myType.MyState = "First";
myType.Show();

MyType tempType = new MyType();

tempType.MyState = myType.MyState;

myType.MyState = "Changed";
myType.Show();

myType.MyState = tempType.MyState;
myType.Show();
}
}
public class MyType
{
private string myState;
public string MyState
{
get { return myState; }
set { myState = value; }
}

public void Show()
{
Console.WriteLine(myState);
}
}

The above code does make what we want with a temporary instance of MyType. and just reassign the state from the temporary to the myType. But you can find it was ugly with exposing the details of the MyType to the Client. what's worse? if the MyType changes it structure( and a field or remove a field. etc.) we got to update the client code. it is verbose and hard. How we resolve this. It is time for the memento pattern.

Actually the memento does use the temporary mechanism, but the memento encapsulate the details of the type to itself and let the Caretaker hold it. It is amazing.

Roles in this pattern

Originator:responsible for creating the memento and recovering from the it
Memento: the very memento to restore the state of the originator at a given time
Caretaker:Responsible for hold the mementor but have no access to update the memento

A small demo to show what i have praised above:

namespace Memento
{
public class Memento
{
private string state;

public Memento(string state)
{
this.state = state;
}

public string State
{
get
{
return this.state;
}
}
}

public class Originator
{
private string state;

public string State
{
get { return this.state; }
set { this.state = value; }
}

public Memento CreateMemento()
{
Memento memento = new Memento(state);
return memento;
}

public void SetMemneto(Memento memento)
{
this.state = memento.State;
}

public void ShowState()
{
Console.WriteLine(this.state);
}
}

public class Caretaker
{
private Memento memento;

public Memento Memento
{
get { return this.memento; }
set { this.memento = value; }
}
}

class Program
{
static void Main(string[] args)
{
Originator originator = new Originator();
originator.State = "First";
originator.ShowState();//show "First"

Caretaker caretaker = new Caretaker();
caretaker.Memento = originator.CreateMemento();

originator.State = "Changed";
originator.ShowState();//show "Changed"

originator.SetMemneto(caretaker.Memento);
originator.ShowState();//show "First" AGAIN
}
}

}

public class MyClient
{
public void StoreWithTheNormalWay()
{
MyType myType = new MyType();
myType.MyState = "First";
myType.Show();

MyType tempType = new MyType();

tempType.MyState = myType.MyState;

myType.MyState = "Changed";
myType.Show();

myType.MyState = tempType.MyState;
myType.Show();
}
}

The newer version with the memento is better and more clarified. Let the originator store and recover by itself.and client even does not know how it works and also does not know the details of the originator which is one of the principles of the OOP.

本文链接