PHPプログラム開発の原則まとめ_PHPチュートリアル
- WBOYオリジナル
- 2016-07-13 17:36:07916ブラウズ
你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起 。 ----- Arthur J.Riel (1)所有数据都应该隐藏在所在的类的内部。 (2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。 (3)尽量减少类的协议中的消息。 (4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。 (5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。 如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。 (6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。 (7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。 (8)类应该只表示一个关键抽象。 包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不 造成任何影响 . (9)把相关的数据和行为集中放置。 设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。 (10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。 朝着稳定的方向进行依赖. (11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。 (12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。 (13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。 规划一个接口而不是实现一个接口。 (14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。 (15)对包含太多互不沟通的行为的类多加小心。 这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。 (16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。 (17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。 (18)从你的设计中去除不需要的类。 一般来说，我们会把这个类降级成一个属性。 (19)去除系统外的类。 系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。 (20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。 (21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。 (22)尽量减少类的协作者的数量。 一个类用到的其他类的数目应当尽量少。 (23)尽量减少类和协作者之间传递的消息的数量。 (24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。 (25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。 (26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。 (27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。 (28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。 当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。 (29)让系统功能在窄而深的继承体系中垂直分布。 (30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。 (31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。 (32) 制約が依存するセマンティック情報が頻繁に変更される場合は、それを一元管理されたサードパーティ オブジェクトに置くのが最善です。 (33) 制約が依存するセマンティック情報がめったに変更されない場合、制約に関係するクラス間で分散するのが最適です。 (34) クラスはそこに何が含まれているかを知る必要がありますが、誰がそれを含んでいるかを知ることはできません。 (35) リテラルスコープを共有する (つまり、同じクラスに含まれる) オブジェクトは、相互に使用関係を持つべきではありません。 (36) 継承は、専門化階層をモデル化するためにのみ使用する必要があります。 (37) 派生クラスは基底クラスを知っている必要があり、基底クラスは派生クラスに関する情報を知っていてはなりません。 (38) 基本クラス内のすべてのデータはプライベートである必要があり、保護されたデータを使用しないでください。 クラスの設計者は、クラスのユーザーが必要としないものをパブリックインターフェイスに決して配置すべきではありません。 (39) 理論的には、継承階層は深くあるべきであり、深ければ深いほど良いです。 (40) 実際には、継承階層の深さは平均的な人の短期記憶容量を超えてはなりません。広く受け入れられている深さの値は 6 です。 (41) すべての抽象クラスは基本クラスである必要があります。 (42) すべての基本クラスは抽象クラスである必要があります。 (43) データ、動作、インターフェースの共通点を継承階層の可能な限りハイエンドに配置します。 (44) 2 つ以上のクラスが共通のデータを共有する (ただし、共通の動作はしない) 場合、共通のデータを 1 つのクラスに配置し、このデータを共有する各クラスにこのクラスを含める必要があります。 (45) 2 つ以上のクラスが共通のデータと動作 (つまり、メソッド) を持つ場合、これらの各クラスは、これらのデータとメソッドを表す共通の基本クラスを継承する必要があります。 (46) 2 つ以上のクラスが共通のインターフェイス (メソッドではなくメッセージを参照) を共有する場合、多態的に使用する必要がある場合にのみ、共通の基本クラスから継承する必要があります。 (47) オブジェクトタイプの表示のケースバイケース分析は一般的に間違っています。このような場合、ほとんどの場合、設計者はポリモーフィズムを使用する必要があります。 (48) 属性値表示のケースバイケース分析は間違っていることが多い。クラスは継承階層に分離し、各属性値を派生クラスに変換する必要があります。 (49) 継承関係を通じてクラスの動的セマンティクスをモデル化しないでください。静的セマンティック関係を使用して動的セマンティクスをモデル化しようとすると、実行時にタイプが切り替わります。 (50)クラスオブジェクトを派生クラスに変えないでください。インスタンスが 1 つしかない派生クラスには注意してください。 (51) 実行時に新しいクラスを作成する必要があると考えられる場合は、一歩下がって、オブジェクトを作成していることを認識してください。次に、これらのオブジェクトをクラスに一般化します。 (52) 派生クラスで空のメソッド (つまり、何も実行しないメソッド) を使用して、基本クラスのメソッドをオーバーライドすることは違法である必要があります。 (53) オプションの組み込みと継承の必要性を混同しないでください。オプションの包含を継承としてモデル化すると、クラスの急増につながります。 (54) 継承階層を作成するときは、再利用可能なコンポーネントではなく、再利用可能なフレームワークを作成するようにしてください。 (55) 設計で多重継承を使用する場合は、間違いがあったと想定してください。間違いを犯していない場合は、それを証明する必要があります。 (56) オブジェクト指向設計で継承が使用されるときは常に、次の 2 つの質問を自問してください: (1) 派生クラスは、それが継承するものの特別な型ですか? (2) 基本クラスは派生クラスの一部ですか? (57) オブジェクト指向設計で多重継承が見つかった場合は、基本クラスが実際に別の基本クラスの派生クラスになっていないことを確認してください。 (58) オブジェクト指向設計において、包含と関連付けのどちらかを選択する必要がある場合は、包含を選択してください。 (59) クラスのオブジェクトの簿記にグローバル データやグローバル関数を使用しないでください。クラス変数またはクラスメソッドを使用する必要があります。 (60) オブジェクト指向の設計者は、物理的な設計原則が論理的な設計を損なうことを許すべきではありません。ただし、論理設計に関する決定を行う際には、物理設計基準を使用することがよくあります。 (61) オブジェクトの状態を変更するためにパブリック インターフェイスをバイパスしないでください。