面向对象设计的目的是消除需求变化对软件的影响
当有一个可能变化的因素时,我们会把这个变换点抽象成接口,让程序依赖这个接口,另写这个接口的实现
这个是面向对象里的依赖倒置原则,也就是说实现细节依赖抽象,而不要抽象依赖实现细节
这样做降低了实现变化对程序的影响.
但是有时候很不幸,如果抽象本身也是不稳定的,或者说程序在两个方面都是易变的,这时候怎么办?
多继承?让实现继承两个接口?
买噶的 想起来就有点恐怖.如果两个方面各有三个变化点,那么最终的变化岂不是会有9种之多?
你必须为每个类不厌其烦地写实现,而且这些实现中每个变化点会出现三次,这就意味着将来牵一发而动全局
恭喜~! 你的设计已经失败了.
Bridge模式中用了比继承更合适的 - 组合
拿鸭子来举个例子
让鸭子一方面的变化(吃睡)继承动物接口,另一方面的变化(羽毛)用组合来实现,这样一个成功的鸭子就被创建出来了.
O(∩_∩)O哈哈~
个人认为,只要深刻理解面向对象的真谛,严守面向对象的原则,管他什么鬼模式呢,这时你会发现你的设计就是模式
让我想起了<<倚天屠龙记>>
张三丰:(看了太极招式)怎么样?
张无忌:都记住了.
(过了一会)
张三丰:现在呢?
张无忌:全忘了.
张三丰:你可以出师了@#$%
或许这就是无招胜有招,重在意而非型
当有一个可能变化的因素时,我们会把这个变换点抽象成接口,让程序依赖这个接口,另写这个接口的实现
这个是面向对象里的依赖倒置原则,也就是说实现细节依赖抽象,而不要抽象依赖实现细节
这样做降低了实现变化对程序的影响.
但是有时候很不幸,如果抽象本身也是不稳定的,或者说程序在两个方面都是易变的,这时候怎么办?
多继承?让实现继承两个接口?
买噶的 想起来就有点恐怖.如果两个方面各有三个变化点,那么最终的变化岂不是会有9种之多?
你必须为每个类不厌其烦地写实现,而且这些实现中每个变化点会出现三次,这就意味着将来牵一发而动全局
恭喜~! 你的设计已经失败了.
Bridge模式中用了比继承更合适的 - 组合
拿鸭子来举个例子
- //Coding by nyzhl
- public interface IFeather
- {
- void Show();
- }
- public abstract class IAnimal
- {
- protected IFeather feather;
- public abstract void Eat();
- public abstract void Sleep();
- public void ShowFeather()
- {
- feather.Show();
- }
- }
- public class DuckFeather:IFeather
- {
- public void Show()
- {
- Console.WriteLine("Duck's Feather");
- }
- }
- public class Duck:IAninal
- {
- //组合
- base.feather = new DuckFeather();
- public void Eat()
- {
- Console.WriteLine("Duck is Eating");
- }
- public void Sleep()
- {
- Console.WriteLine("Duck is Eating");
- }
- }
让鸭子一方面的变化(吃睡)继承动物接口,另一方面的变化(羽毛)用组合来实现,这样一个成功的鸭子就被创建出来了.
O(∩_∩)O哈哈~
个人认为,只要深刻理解面向对象的真谛,严守面向对象的原则,管他什么鬼模式呢,这时你会发现你的设计就是模式
让我想起了<<倚天屠龙记>>
张三丰:(看了太极招式)怎么样?
张无忌:都记住了.
(过了一会)
张三丰:现在呢?
张无忌:全忘了.
张三丰:你可以出师了@#$%
或许这就是无招胜有招,重在意而非型