设计模式之单一职责原则学习

单一职责原则：就一个类而言应该仅有一个引起它变化的原因。

比如写一个窗口应用程序。我们会创建一个类，将各种各样的代码，如某种算法的代码或是访问数据库的代码，都放在这个类中。以后一旦需求有所更改就必须修改这个类。各个功能的耦合性太大，牵一发而动全身。维护很麻烦，复用不可能，也缺乏灵活性。

由于c语言是我的第一门编程语言，这么多年的使用，面向过程的思想早已根深蒂固。短时间很难培养起使用面向对象开发的习惯。看来任何东西都有两面性，在学C++之前先学习C语言可能对入门有帮助，但也有一些弊端。世上很多东西都是矛盾的，重要的是要从这些矛盾中找到一个平衡点。

如果一个类承担的功能过多，就等于把这些职责偶合在一起，一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏。

俄罗斯方块游戏的设计

应该考虑将程序至少分为两个类：一个是窗口类，用于处理界面交互。另一个是游戏逻辑类。当有一天要改变界面或是移植到其他平台上就不涉及游戏逻辑的改变。

对于游戏逻辑设计，方块的可移动区域，可以用一个二维数组进行表示。对方块的各种操作就是对二维数组值进行的操作。。我觉得也需要两个大类，首先是各种图形的表示类，比如口型，L型，1型。给出它的各个成员在二维数组的坐标。它们应该从一个共同的基类继承。另外一个是对图形类进行操作的操作类。比如左移、右移、变形以及碰撞检测、消行等。可以考虑使用策略模式来对各个图形类进行管理。

    代码稍后奉上。。。。。

      软件设计真正要做的内容，就是发现职责并把那些指职责分离。如果能找出多于一个动机去改变一个类，这个类就具有多个职责，此时就应该考虑职责分离。