|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
如果你单纯是为了做网站赚钱,我想你还是别学php的好,去学ASP,JSP好了,毕竟它们有实力雄厚的公司去支持它们。 你不用严厉恪守这些准绳,违反它们也不会被处以宗教科罚。但你应该把这些准绳当作警铃,若违反了个中的一条,那末警铃就会响起 。 ----- 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)束缚所依附的语义信息假如常常改动,那末最好放在一个集中式的第3方对象中。
(33)束缚所依附的语义信息假如很少改动,那末最好散布在束缚所触及的各个类中。
(34)类必需晓得它包括甚么,然而不克不及晓得谁包括它。
(35)同享字面局限(也就是被统一个类所包括)的对象互相之间不该当有利用关系。
(36)承继只应被用来为特化条理布局建模。
(37)派生类必需晓得基类,基类不该该晓得关于它们的派生类的任何信息。
(38)基类中的一切数据都应该是公有的,不要利用回护数据。
类的设计者永久都不该该把类的利用者不需求的器材放在私有接口中。
(39)在实际上,承继条理系统应该深一点,越深越好。
(40)在理论中,承继条理系统的深度不该当超越一个通俗人的短时间记忆才能。一个广为承受的深度值是6。
(41)一切的笼统类都应该是基类。
(42)一切的基类都应该是笼统类。
(43)把数据、行动和/或接口的个性尽量地放到承继条理系统的高端。
(44)假如两个或更多个类同享公共数据(但没有公共行动),那末应该把公共数据放在一个类中,每一个同享这个数据的类都包括这个类。
(45)假如两个或更多个类有配合的数据和行动(就是办法),那末这些类的每个都应该从一个暗示了这些数据和办法的公共基类承继。
(46)假如两个或更多个类同享公共接口(指的是动静,而不是办法),那末只要他们需求被多态地利用时,他们才应该从一个公共基类 承继。
(47)对对象类型的显示的分情形剖析通常为毛病的。在大多半如许的情形下,设计者应该利用多态。
(48)对属性值的显示的分情形剖析经常是毛病的。类应该解耦分解一个承继条理布局,每一个属性值都被变换成一个派生类。
(49)不要经由过程承继关系来为类的静态语义建模。试图用静态语义关系来为静态语义建模会招致在运转时切换类型。
(50)不要把类的对象酿成派生类。对任何只要一个实例的派生类都要多加当心。
(51)假如你感觉需求在运转时辰创立新的类,那末退后一步以认清你要创立的是对象。如今,把这些对象归纳综合成一个类。
(52)在派生类顶用空办法(也就是甚么也不做的办法)来覆写基类中的办法应该长短法的。
(53)不要把可选包括同对承继的需求相搅浑。把可选包括建模成承继会带来众多成灾的类。
(54)在创立承继条理时,试着创立可复用的框架,而不是可复用的组件。
(55)假如你在设计中利用了多重承继,先假定你犯了毛病。假如没出错误,你需求想法证实。
(56)只需在面向对象设计顶用到了承继,问本人两个成绩:(1)派生类是不是是它承继的谁人器材的一个特别类型?(2)基类是否是派生类的一局部?
(57)假如你在一个面向对象设计中发明了多重承继关系,确保没有哪一个基类实践上是另外一个基类的派生类。
(58)在面向对象设计中假如你需求在包括关系和联系关系关系间作出选择,请选择包括关系。
(59)不要把全局数据或全局函数用于类的对象的薄记任务。应该利用类变量或类办法。
(60)面向对象设计者不该当让物理设计原则来损坏他们的逻辑设计。然而,在对逻辑设计作出决议计划的过程当中咱们常常用到物理设计原则。
(61)不要绕开公共接口去修正对象的形态。
如果你单纯是为了做网站赚钱,我想你还是别学php的好,去学ASP,JSP好了,毕竟它们有实力雄厚的公司去支持它们。 |
|