设计原则
- 格式：docx
- 大小：908.86 KB
- 文档页数：11
Assignment 2 设计原则与包设计原则分析银行系统与社团管理系统
1.系统介绍
这个银行系统是刚上大一学完java后做的一个项目，再学过这么多的设计原则后，发现这个项目设计存在很大的问题，根本没有实现高内聚，低耦合的设计目标，并且代码冗余，重用率很低，没有丝毫的层次感。
下面我们来看看整个系统类的设计。
再考虑到真个银行系统的包设计过于简单，我们通过另一个社团管理系统来进行包设计的分析。
其中banking.domain包中的类是用来实现银行业务逻辑的处理过程，包括查询账户以及存款，取款等业务过程以及不同账户的实体类。
Banking.reports用来表示出用户的账户余额。
BankServer是用来作为银行段的服务器，用来进行数据交互。
BankUI中的类用来进行管理员对用户的增删改查功能以及管理员和用户进行与系统交互的界面。
下面就从设计原则以及包设计原则来分析这个银行管理系统.
2.五项设计原则
2.1职责单一原则
所谓职责单一原则是指，就一个类而言，应当只有一个引起它变化的原因。
就拿系统中的Create.java这个类
来说：
从代码中我们可以看到，这个Create类不仅仅有连接数据库的方法，并且还有执行创建用户的方法，一旦这两个方法当中有一个进行改变就会影响整个类的设计。
因此这个类违背了职责单一原则。
改进的话则应当将连接数据库的方法封装到一个新的类中，然后再Create类中进行调用，Create 类仅仅单一的实现创建用户的方法。
2.2开放封闭原则
所谓开放封闭原则就是，面对需求，对程序的改动是通过增加新的代码，而不是更改现有的代码。
就拿系统中的Account，CheckingAccount，SavingAccount这3个类来说。
他们满足下列的关系
Account
+balance：int；
-withdraw（）；
CheckingAccount -withdraw（）；SavingsAccount -withdraw（）；
由此可以看到两个账户ChekingAccount，
SavingsAccount都继承了Account这个类，当想再次添加一个账户只需要构建一个实体类来继承Account这个类即可，而不需要改动其他已经写好的代码。
从这点上来说，这么设计是满足开放封闭原则的。
2.3 里氏替换原则
所谓里氏替换原则，是指一个软件实体如果使用的是一个父类的话，那么一定适用于其子类。
也就是说，在软件里面，把父类替换成子类的话，程序的行为没有变化。
就上面那个Account实体作为父类，当将Account换成其子类ChekingAccount，他依然可以正常的实现withdraw（）方法，因此设计是满足里氏替换原则的。
2.4 依赖倒转原则
所谓依赖倒转原则，是指抽象不应该依赖于细节，细节应该依赖抽象。
说白了是指要针对接口编程，而不是实现细节编程。
就拿本系统中银行管理员对用户进行增删改查的功能：
我们可以看到这个都是实现整个系统的细节，但是在此之前并没有进行接口的定义，而是只能通过增删改查这几个功能进行编程。
因此违背了依赖倒转原则。
要是改进的话，应当定义一个接口，然后根据不同的选择来进行调用不同的类进而实现功能。
2.5 接口分离原则
对于接口隔离原则，其核心思想是：使用多个小的专门的接口，而不要使用一个大的总接口。
纵观整个系统，我们可以看到有用户与管理员这两种人与系统交互，但是两个所对应的实现功能确实不同的。
因此在设定接口的时候我们需要基于用户与管理员分别设定一个接口，进而实现不同的功能。
而不是只设定一个接口，将所有方法都放在里面，让用户或者管理员去实现。
3.包设计原则
由于上一个银行管理系统只存在2个包之间存在关联关系，所以我们选择了另一个系统进行了包设计的分析。
包的设计如下：
这个是一个社团管理系统，采用MVC架构，这里的代码单纯的列出了逻辑处理的过程，以及数据调用的过程。
这几个包的关联关系如下图所示：
2.1 重用等价原则
所谓重用等价原则就是指，一个包中的类要么都可以
重用，要么都不能重用。
所谓重用，多是指用户在使用此
系统时无需看它的源代码。
就拿这个系统来说，dao层中
均是调用数据层的处理逻辑，因此无需看到源代码，他是
满足于重用等价原则的。
2.2无环依赖原则
所谓无环依赖原则就是指，在包之间的依赖关系当中不存在环形结构。
从最上面的包之间依赖关系图中我们可
以清楚的看到包之间的依赖关系并没有形成一个环，因此
它满足无环依赖原则。
2.3稳定依赖原则
所谓稳定依赖原则是指一个包应当依赖于另一个更加更定的包。
其中dao包应该是最稳定的，无论发生什么变
化，对dao包的影响都不大，因此dao包应当放在最底
层。
而action包会根据业务需求的变化而变化，因此是
最不稳定的。
2.4稳定抽象原则
所谓稳定抽象原则就是指最稳定的包应该是最抽象的包，越抽象的包应当越稳定而越现实包应当越不稳定。
然后整个包设计当中dao包是具体实现包，并且不含有抽象类，因此违背了稳定抽象原则。
我认为应当定义一个service接口来定义service类的实现方法，从而实现稳定
抽象原则。
2.5共同封闭原则
在这个系统中，我们将业务控制全都放入到action包中，将数据处理全都放入到dao层。
对于同一种类型的类
全都放入放相同的包中，这一点是满足共同封闭原则。
