腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

一点博客

JAVA技术研习。

专栏作者

50

文章

44036

阅读量

12

订阅数

JAVA设计模式详解

编程算法面向对象编程

设计模式有两种分类方法，即根据模式的目的来分和根据模式的作用的范围来分。根据目的来分根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式 3 种。创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。GoF 中提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。

2019-07-24

4570

Spring Security框架入门

http spring php 面向对象编程 html

Spring Security是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。它提供了一组可以在Spring应用上下文中配置的Bean，充分利用了Spring IoC，DI（控制反转Inversion of Control ,DI:Dependency Injection 依赖注入）和AOP（面向切面编程）功能，为应用系统提供声明式的安全访问控制功能，减少了为企业系统安全控制编写大量重复代码的工作。

2019-07-24

3930

61条面向对象设计的经验原则

面向对象编程

你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。　　(1)所有数据都应该隐藏在所在的类的内部。p13 　　(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。p15 　　(3)尽量减少类的协议中的消息。p16 　　(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。 p16 　　(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。p17 　　如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。　　(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。p17 　　(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。 p18 　　(8)类应该只表示一个关键抽象。p19 　　包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 . 　　(9)把相关的数据和行为集中放置。p19 　　设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。　　(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。p19 　　朝着稳定的方向进行依赖. 　　(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。p23 　　(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。p30 　　(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。p30 　　规划一个接口而不是实现一个接口。　　(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。p30 　　(15)对包含太多互不沟通的行为的类多加小心。p31 　　这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。　　(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。p33 　　(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。p36 　　(18)从你的设计中去除不需要的类。p38 　　一般来说，我们会把这个类降级成一个属性。　　(19)去除系统外的类。p39 　　系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。　　(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。p40 　　(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。p43 　　(22)尽量减少类的协作者的数量。p52 　　一个类用到的其他类的数目应当尽量少。　　(23)尽量减少类和协作者之间传递的消息的数量。p55 　　(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。p55 　　(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。p55 　　(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。p55 　　(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。p57 　　(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。p57 　　当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。　　(29)让系统功能在窄而深的继承体系中垂直分布。p58 　　(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。p60 　　(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。p60 　　(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。p60 　　(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。p60 　　(34)类必须知道它包含什么，但是不能知道谁包含它。p61 　　(35)共享字面范围(也就是被同一个类

2019-07-24

5450

没有更多了

社区活动

腾讯技术创作狂欢月

“码”上创作 21 天，分 10000 元奖品池！

Python精品学习库

代码在线跑，知识轻松学

博客搬家 | 分享价值百万资源包

自行/邀约他人一键搬运博客，速成社区影响力并领取好礼

技术创作特训营·精选知识专栏

往期视频·千货材料·成员作品最新动态