马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有账号？立即注册
×
前言
讲堂上，老师展示了两个非常范例的反面讲义：一个是 Sunny 软件公司的 CRM 图表体现体系，另一个是基于 Java C/S 体系的登录功能。这两个案例固然业务场景差异，但都指向了软件计划中两个最焦点的痛点：怎样面对厘革（开闭原则）以及怎样界定责任（单一职责原则）。
在第一个案例中，Sunny 公司开辟了一个 CRM 体系，须要体现饼状图（PieChart）和柱状图（BarChart）。原始的计划方案如图所示：有一个 ChartDisplay 类，内里有一个 display(String type) 方法。
这种计划严峻违背了开闭原则。
若我们要加一个折线图（LineChart）。”按照原来的写法，我们必须修改 ChartDisplay 类的源代码，在 display 方法里增长一个 if (type.equals("line")) 的判断分支。
重构方案：多态与抽象
为了符合“对扩睁开放，对修改关闭”的原则，我们须要引入抽象。
我们可以界说一个抽象的图表接口或父类 AbstractChart ，此中包罗一个抽象方法 display() 。然后让 PieChart 和 BarChart 分别去实现这个接口。
// 抽象层
public interface Chart {
void display();
}
// 详细实现
public class PieChart implements Chart {
public void display() { System.out.println("体现饼状图"); }
}
public class BarChart implements Chart {
public void display() { System.out.println("体现柱状图"); }
}
如许一来， ChartDisplay 类就不再依靠详细的图表类，而是依靠抽象的 Chart 接口。当须要新增折线图时，我们只须要新建一个 LineChart 类实现接口即可，完全不须要修改原有的 ChartDisplay 代码。
第二个案例展示了一个名为 Login 的类，它简直是一个“全能工具箱”。请看它的成员方法：
init() ：初始化
display() ：界面体现
validate() ：数据校验
getConnection() ：数据库毗连
findUser(...) ：业务查询
main(...) ：步伐入口
这个类严峻违背了单一职责原则（Single Responsibility Principle, SRP）。
一个类应该只有一个引起它厘革的缘故原由。但在上面的 Login 类中，如果 UI 变了要改它，数据库暗码变了要改它，验证逻辑变了也要改它。这就导致代码耦合度极高，牵一发而动满身，维护起来简直是噩梦。
重构方案：职责分离
我们须要将这个巨大的类举行拆分：
UI 层：将 display() 和 init() 剥离出来，放入 LoginView 类，专门负责界面交互。
数据访问层（DAO）：将 getConnection() 和 findUser() 剥离出来，放入 UserDAO 类，专门负责和数据库打交道。
业务逻辑层：保存 validate() 在 LoginService 或 LoginController 中，作为调和者，调用 View 获取数据，调用 DAO 验证数据。
结语
无论是 CRM 图表体系的重构，照旧登录类的拆分，其焦点头脑都是解耦。
开闭原则告诉我们要用“抽象”来隔离厘革，让体系易于扩展。
单一职责原则告诉我们要用“分工”来低沉复杂度，让体系易于维护。
免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金. |
发表于