Design Patterns - Getting to Know

Design patterns are not unfamiliar to everyone, but the things in them are the same as martial arts. It is easy to understand, otherwise you will always know, but they are all furs. I will borrow the ones in the Head First book to think of me. If you are new to , think outside the box and understand why you should use design patterns:

Suppose, now to make a game that simulates ducks, how should I design it?

We first design a duck superclass (Superclass), and then let all kinds of ducks integrate this class. Of course, some public methods are defined in it, and all ducks have them.

public class Duck {
	
	public void quack() {// quack}
	
	public void swin(){// swimming}
	// Other methods..
}

Two other classes: MallerDuck and RedheadDuck, implement their own skins

public class MallarDuck extends Duck{
	public void display(){
		// mallard duck
	}
}

public class RedheadDuck extends Duck{
	public void display(){
		// red duck
	}
}

OK, then now the company requires that ducks can fly. Maybe you say simple, add a fly() method to the parent class

public class Duck {
	public void quack() {
		// croak
	}
	public void swin(){
		// Swim
	}
	public void fly(){
		// fly
	}
}

But when the test was carried out, it was found that many toy ducks were flying... and the boss was very embarrassed. At the beginning, the client didn't say there was a toy duck? But the development understands that the requirements are variable, and it is always pursuing greater interests. As long as the users are satisfied, there is no way.

Carefully, you can override the method, so the toy duck has its own behavior, and it can't fly.

public class DecoyDuck extends Duck{
	public void quack() {
		// toy duck, chirping
	}
	public void swin(){
		// Swim
	}
	public void fly(){
		// do nothing, can't fly
	}
        public void display(){
		// this is the toy duck
	}
}

Now I have received news that in order to innovate, there may be various ducks, but many fly() and other methods will be the same, so don't you have to repeat many fly() and quart() methods? Will write A lot, pain! At this time, I think of interfaces, which are designed for special behaviors and implemented only when needed.

public interface Quackable {
	public void quack();
}

public interface Flyable {
	public void fly();
}

// etc

Then others go to implement the interface

public class MallarDuck implements Flyable,Quackable{
	public void display(){
		// mallard duck
	}
	@Override
	public void fly() {
	}

	@Override
	public void quack() {
	}
}
// other similar

But this still feels that there is no substantial progress. If there are more than N ducks, how much code must be repeated!

This leads us to a truth: in software development, the only thing that doesn't become is change.

I am reminded of a saying that is often said: Design exists because of the future

The code at this time is not good in terms of reusability, complexity and modification. We introduce a very important design principle:

Find out the parts of the program that may need to change, separate them out, encapsulate them, and don't put them together with code that doesn't need to change . The result is that parts that need to be changed can easily be changed or extended without causing other parts that do not need to be changed.

In order to achieve code reuse and facilitate expansion, I first separate Duck from swimming(), and then take out fly() and quack(), which will become behaviors, and see how the code does it:

public class Duck {
	public void swin(){
		// swimming, common part
	}
}

public interface FlyBehaviour {
        // The interface for flying this behavior, the same is true below
	public void fly();
}
public interface QuackBehaviour {
        // 叫的接口
	public void quack();
}

public class FlyWithWing implements FlyBehaviour{
	@Override
	public void fly() {
		// 会飞的 鸭子
		// 具体实现，可以共用的代码，下面同理
	}
}
public class FlyNoWay  implements FlyBehaviour{
	@Override
	public void fly() {
		// 不会飞 的鸭子
	}
}
// 下面 quck 同理

public class QuackOne implements QuackBehaviour{
	@Override
	public void quack() {
		// 普通鸭子 呱呱叫
	}
}
public class QuackTwo implements QuackBehaviour {
	@Override
	public void quack() {
		// 橡皮鸭子  唧唧叫
	}
}

OK，现在的代码，灵活性就更高了。比如我现在可能会添加更多的鸭子，那么无论是会飞的，不会飞的，这些代码是可以重用的，如果需要添加另外的叫声，我们同样可以创建一个新的QuackThree 去实现接口，也是可以扩展的，现在的代码是不是好很多了呢？

说了这么多，我们初略分析一下，拿到需求的时候，不要简单的直接开始写代码，为了程序的灵活性，我们应当做一些考虑，这样为我们以后减少工作量做准备。因为程序时间长的部分是维护，开始时间最短，那么我们应该这样去思考，形成习惯，慢慢代码就会好很多了。

Design Patterns - Getting to Know

Guess you like