面向对象编程思想

     事情往往是被简单解决的，如果做复杂了，往往是方法不正确

一：访问本对象属性最好加上this,让调用更清晰

       因为面向对象的设计中会设计到属性，而该类的每个方法都能直接访问到属性

      所以最好都加上this，避免混乱

二：请求应答中的面向对象

      请求应答的方式，有时间很难运用这种思想，让我们很自然而然得去使用原始的

     算法加数据(model)的方式，但是如果我们设计到相对复杂点的交互，我们可以考虑

     Action仅仅用于中转，逻辑部分严格按照面向对象的设计,model只负责与前台数据传输

     一般来说传输的数据都不会很多的，可由对象生成

      

三：方法合并原则

    1：如果方法完成的功能一样只是有个参数不一样，我们完全可以把方法写到一起通过传参数传递

         方式去完成不同的，当然参数是方法内部直接用，如果用于判断那是控制耦合那就不好了

 

四： 回调函数，关联思想

     两个页面之间需要的关联可以考虑回调函数(传方法指针)与传对象思想

     这样两个页面之间的关系就很好控制了

      可以用回调函数很好的执行另外页面传的方法

     对象也一样

五：尽量减少全局变量的使用，相关全局变量多于1，类分解

      如果必须要使用全局变量且相关的操作多于一个时,就是一个需要类分解的信号,

      照成这样的原因就是你把两个不同类型的类整合到一起的结果，所以这个时候就需要拆分类.

      这样可以减少全局变量的污染，类的单一性原则,

      这样需要使用的时候只需要实例化然后在调用传参数的方式就可以了

      例如斗地主游戏倒计时他需要倒计时的可能是自己也可以是另外两个用户，还有开始暂停等等，

      这些情况说他这应该单独提出一个类来管理

      这样就可以尽可能的吧逻辑给交给另外的类来管理

     而且全部变量可以单独用一个model来存放   

六：类型相同方式不同，使用接口抽象

     当你在写代码时发现一个类的代码越来越多，且他们都可以统一出一个类型来比如ORM的更新，

     虽然更新的方式有很多种，但是他们都属于更新。这个就是可以抽象 
     的信号,就需要用一个接口抽象出来不同的类去实现他，这样那个解析接口
     的类也就该类型的入口可以很少，不同的类型的实现类代码也很少，而且无论更新的方式有多少种，入口也不需要改变
     ，这样想要增加类型，升级代码也非常方便.但是
     如果不同方式的方法都写在一起，代码会越来越臃肿，不仅看起来不舒服
     也不方便维护，但是往往我们大类型的抽象了，有些小类型习惯性的就写下来的。

     (其实更新删除插入可以抽象出同一个接口,他们有反射创建sql语句的共同点,当然如果查询不是用户直接输入的sql也可以实现该接口)

七：不要进行if,else编程，尽量少使用判断

      如果你的项目中大量使用使用判断,例如:if else,swich case

     那说明你的架构不合理，没有进行合理的抽象。一个真正好的架构，

     在架构上是不需要判断的，除了具体的实现算法判断就非常少的。

     因为本来就是一个一个的对象，执行对象自己的方法，怎么会需要判断了。

     所以在整体宏观的架构上是不需要判断的，判断只是在具体实现的时候使用

     例1：我们要做一个彩票玩法，一个彩票可能有很多种投注方法，每种的规则都不一样,

                 如果我们直接这么写下来那不是有多少规则就需要写多少个规则，然后用siwtch case

                去关联，这样写多了逻辑会很混乱很难维护，所以改进一下架构

                

                既然每种玩法都有动态生成界面的方法(create),验证规则方法 (isrule),

               注数算法等等方法,那么为什么我们不可以用一个接口 (Iloteryplaytype)把他们抽象出来，

               每种玩法去实现那个接口，这样每种玩法的逻辑就可以完全拆分开来，不需要
               用很多siwtch case去关联对应的方法，不需要任何的判断，只需要一个入口用接口去接收具体的类，
               在点击玩法的时候就可以把自己的对象传到入口去解析，投注时也只需 要传当前的对象。
               这样后期要加玩法也很方便只需要写一个玩法类去实现接口就可以了， 不需要改动任何代码。

     例2：Orm的代码生成器，解析参数的方式有很多种，join的参数,一般的参数,is null类型参数，

               开始往往我们习惯性的就写成了判断的方式,type=1怎么去解析,type=2怎么取解析，这种做法是很不好的，

                这时就需要把不同的类型写成不同的对象解析     

     凡是需要if else,switch等判断的地方,我们要去想一下，每个分支是不是可以写成一个单独的对象，

     他们拥有相同的方法，如果可以就可以使用接口抽象，而不需要使用判断，这样就可以降到耦合性,

     而使用if,else的地方往往都可以抽象只是需不需要的问题

       

八：界面后台动态创建思想

              如果前端展示变化比较大，层次比较多可以考虑有后台动态生成界面，不论是html,siverlight,winfrom只要是

             前端展示的，这样可以有更高的灵活性与重用性，可以运用面向对象的思想，很多

             问题就可以简单解决了

九: 高度抽象，单一类型思想

      如果一个类中你可以分解成多种类型的组合，那么可以考虑拆分了

      这点是非常重要的，什么模块化也不过是把各种小的对象组合起来，只要

      你把每种类型都用一个对象去表示，

      也不是说你把每个小类型都分开就一定要用接口抽象，而是逻辑会非常清晰，

      交互都是对象之间的交互，而不是各种判断搅在一起。不管怎么变动整体不会变，后期就也很好组合和抽象。

      单一原则，各模块相互独立，非常利于团队合作，任务分配