For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
程序员在学习Java编程开发语言的时候都要重点学习编程类的应用,今天我们就通过案例了解一下,Java编程类的应用与优化方法。
对于一些有扩展需求的类,尽管他们可能满足单一职责以及内聚属性。但是由于这种类本身的扩展性,导致我们会在新的业务需求的时候频繁地对这种类进行修改与新方法的增加。这种修改导致的问题是在每一次修改代码或者新增方法的时候都无法保证不会对原有的功能造成影响。虽然我们可以通过单元测试或者集成测试来验证我们的修改,但是这都会增加我们的工作量。
所以,对于可能会频繁修改、并进行业务追加的方法类,我们需要特别的为其保留扩展性。我们可以通过实现统一接口或者继承抽象类、父类的方法,来获得多个不同扩展能力的子类,而这些子类我们也可以通过策略模式或者责任链模式来组织。
对于类来说,对其进行扩展总是好与对其直接进行修改。
2、可测试
关于这个角度,其实是源于我的另一个问题,就是在传统的三层框架下,中间的service层我们是否需要编写一层接口(interface)。我原来的认知是,实际上在绝大多数的情况,这个service我们是不会再进行其他实现的,所以单独写一个接口然后再增加对应的Impl只会让我们在扩展方法的时候更加的繁琐。
但是现在我发现了直接的用处,那就是:支持了单元测试的进行。
如果我们直接依赖具体的细节,就会对我们的测试带来挑战。具体来说,如果我们依赖于一个具体的类的实现的话,那么当我们希望针对其中的细节进行测试的话我们就要对细节之外的内容进行调整,可能包括:系统时间、数据库字段等内容。但如果我们是使用接口对servce进行调用,那么在我们测试的时候就可以通过直接编写测试用的service来实现预期的返回内容。从而大大简化进行测试的难度。
3、内聚
我们在进行面对对象编程的时候经常说的就是类需要“高内聚、低耦合”。我们把类中的方法操作类中的属性称做方法与属性的关联的话,那么关联越多的类就是越内聚的。极端一点的话,如果类内所有的方法都使用所有的类属性的话,那么这个类是为内聚的。实际情况并不总是如此理想,所以我们可以根据这种关联关系来判断类中的内容是否足够内聚。
所以,如果你发现在在写完类了之后部分方法只与部分属性产生关联,而其他方法则与另外的属性产生关联,就说明这两部分之间是没有内聚性的。那么我们就可以将其拆分为两个类,而这两个类之间将更加的内聚:方法与属性互相依赖称为了一个整体。
当我们通过内聚性来分析类后,可能会将一个大类,拆分为多个小类。这样会增加类的数量从而增加类的复杂性,同时也会让整体的代码变多。但是类本身可以通过包路径来进行分类,所以这种拆分我认为是比较合理的。