安全设计原则
2012-03-24
1331
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《
阿里云开发者社区用户服务协议》和
《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写
侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：
https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/principles.
目录
相关文章
|
8月前
|
设计模式
关系型数据库
数据安全/隐私保护
软件架构设计原则之单一职责原则
单一职责（Simple Responsibility Pinciple，SRP）是指不要存在多于一个导致类变更的原因。假设我们有一个类负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能导致另一个职责的功能发生故障。这样一来，这个类就存在两个导致类变更的原因。如何解决这个问题呢？将两个职责用两个类来实现，进行解耦。后期需求变更维护互不影响。这样的设计，可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。总体来说，就是一个类、接口或方法只负责一项职责。
66
0
0
|
8月前
|
设计模式
人工智能
Java
软件架构设计原则之依赖倒置原则
依赖倒置原则（Dependence Inversion Principle，DIP）是指设计代码结构时，高层模块不应该依赖低层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。通过依赖倒置，可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并且能够降低修改程序所造成的风险。接下来看一个案例，还是以Course（课程）为例，先来创建一个类Tom：
62
0
0
|
4月前
浅谈设计原则
什么是单一职责原则，在我理解看来就是一个东西如果发生问题那么就有且仅有一个原因导致它发生问题。它的准确解释就是，就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于耦合度加大，当变化发生时，设计会受到破坏。最好的例子就是将界面和业务进行分离。做设计应该让类只有一个职责。
23
0
0
|
8月前
|
设计模式
人工智能
前端开发
软件架构设计原则之开闭原则
开闭原则（Open-Closed Principle，OCP）是指一个软件实体（如类、模块和函数）应该对扩展开放，对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。它强调的是用抽象构建框架，用实现扩展细节，可以提高软件系统的可复用性及可维护性。开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定、灵活的系统。例如版本更新，我们尽可能不修改源代码，但是可以增加新功能。
88
0
0
|
8月前
|
设计模式
关系型数据库
软件架构设计原则之迪米特法则
迪米特原则（Law of Demeter LoD）是指一个对象应该对其他对象保持最少的了解，又叫最少知道原则（Least Knowledge Principle，LKP），尽量降低类与类之间的耦合度。迪米特原则主要强调：只和朋友交流，不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称为成员朋友类，而出现在方法体内部的类不属于朋友类。
68
1
1
|
8月前
|
设计模式
关系型数据库
软件架构设计原则之接口隔离原则
接口隔离原则符合我们常说的高内聚、低耦合的设计思想，可以使类具有很好的可读性、可扩展性和可维护性。我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括对以后有可能发生变更的地方还要做一些预判。所以，对于抽象、对于业务模型的理解是非常重要的。下面我们来看一段代码，对一个动物行为进行抽象描述。
58
0
0
|
8月前
|
设计模式
关系型数据库
软件架构设计原则之里氏替换原则
里氏替换原则（Liskov Substitution Principle，LSP）是指如果对每一个类型为T1的对象o1，都有类型为T2的对象O2，使得以T1定义的所有程序P在所有的对象O1都替换成O2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。
55
0
0
|
设计模式
领域建模
数据库
|
设计模式
关系型数据库
|
设计模式