前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >软件设计原则

软件设计原则

作者头像
疯狂的技术宅
发布2019-03-28 11:32:24
8180
发布2019-03-28 11:32:24
举报
文章被收录于专栏:京程一灯京程一灯

翻译: 疯狂的技术宅 来源: Programmer Gate 原文标题: Software design principles 英文原文: http://programmergate.com/software-design-principles/

软件设计一直是开发周期中最重要的阶段,在设计弹性和灵活的体系结构的花费的时间越多,在将来出现变更时就越节省时间。需求总是变化的,如果不定期添加或维护功能,软件将出现为遗留问题,并且变更成本是根据系统的结构和体系结构来确定的。在本文中,我们将讨论有助于创建易于维护和可扩展的软件的关键设计原则。

1. 一个实际的场景

假设老板要求你写一个将word文档转换成PDF的程序。这个任务看起来很简单,只需找到一个可靠的库,它可以将word文档转换成PDF,并把它集成到你的程序中。在做了一些研究之后,你最终决定使用 Aspose.words 框架并创建了以下类:

代码:PDFConverter.java

代码语言:javascript
复制
/** * A utility class which converts a word document to PDF * @author Hussein * */public class PDFConverter {    /**     * This method accepts as input the document to be converted and      * returns the converted one.     * @param fileBytes     * @throws Exception      */    public byte[] convertToPDF(byte[] fileBytes) throws Exception    {        // We're sure that the input is always a WORD. So we just use         //aspose.words framework and do the conversion.        InputStream input = new ByteArrayInputStream(fileBytes);        com.aspose.words.Document wordDocument = new com.aspose.words.Document(input);        ByteArrayOutputStream pdfDocument = new ByteArrayOutputStream();        wordDocument.save(pdfDocument, SaveFormat.PDF);        return pdfDocument.toByteArray();    }}

生活很简单,一切都很顺利!!

需求总是变化

几个月后,一些用户要求支持也 excel 文档,所以你又做了一些研究,决定使用ascell.cell 。然后你找到你原来的类,并添加了一个名为 documentType 的新字段,并修改了你的方法,代码如下:

代码:PDFConverter.java

代码语言:javascript
复制
public class PDFConverter {    // we didn't mess with the existing functionality, by default     // the class will still convert WORD to PDF, unless the client sets     // this field to EXCEL.    public String documentType = "WORD";    /**     * This method accepts as input the document to be converted and      * returns the converted one.     * @param fileBytes     * @throws Exception      */    public byte[] convertToPDF(byte[] fileBytes) throws Exception    {        if(documentType.equalsIgnoreCase("WORD"))        {            InputStream input = new ByteArrayInputStream(fileBytes);            com.aspose.words.Document wordDocument = new com.aspose.words.Document(input);            ByteArrayOutputStream pdfDocument = new ByteArrayOutputStream();            wordDocument.save(pdfDocument, SaveFormat.PDF);            return pdfDocument.toByteArray();        }        else        {            InputStream input = new ByteArrayInputStream(fileBytes);            Workbook workbook = new Workbook(input);            PdfSaveOptions saveOptions = new PdfSaveOptions();            saveOptions.setCompliance(PdfCompliance.PDF_A_1_B);            ByteArrayOutputStream pdfDocument = new ByteArrayOutputStream();            workbook.save(pdfDocument, saveOptions);            return pdfDocument.toByteArray();        }    }}

该代码可以为新用户正常正常,而且仍然可以按照预期的方式为现有的用户工作,但是一些糟糕的设计气味开始出现在代码中,这样做是不完美的,当再一个新的文档类型时,我们将无法轻松修改这个类。

  1. 代码重复:正如你所看到的,在if/else块存在类似的代码,如果有一天再添加不同的扩展,那么将会出现大量的重复。如果我们决定返回一个文件而不是一个 byte[] 那么就必须在所有的块中做相同的修改。
  2. 刚性:所有的转换算法都是在同一种方法中进行耦合的,所以如果你改变了一些算法,其他的算法也会随之受到影响。
  3. 固定:上面的方法直接依赖于documentType字段,假如一些用户在调用convertToPDF()之前忘记了设置这个字段,那将得不到预期的结果,我们也不能在任何其他项目中重用该方法,因为它依赖于字段。
  4. 高级模块与框架之间的耦合:如果将来我们决定用更可靠的方式替换 Aspose 框架,那么最终修将会改整个 PDFConverter 类,并且会有许多用户受到影响。

正确的方式

通常情况下,并不是所有的开发人员都能够预见未来的变化。因此,他们中的大多数人将会像我们第一次实现的那样,完全实现程序,但是在第一次改变之后,情况就会变得很明显,将来会发生类似的变化。所以,好的开发人员将会为了尽可能减少将来变更的成本使用正确的方式,而不是用if / else块实现。所以我们在暴露的工具(PDFConverter)和低级转换算法之间创建一个抽象层,并将每个算法移动到一个单独的类中,如下所示:

代码:Converter.java

代码语言:javascript
复制
/** * This interface represents an abstract algorithm for converting * any type of document to PDF. * @author Hussein * */public interface Converter {    public byte[] convertToPDF(byte[] fileBytes) throws Exception;}

代码:ExcelPDFConverter.java

代码语言:javascript
复制
/** * This class holds the algorithm for converting EXCEL * documents to PDF. * @author Hussein * */public class ExcelPDFConverter implements Converter{    public byte[] convertToPDF(byte[] fileBytes) throws Exception {        InputStream input = new ByteArrayInputStream(fileBytes);        Workbook workbook = new Workbook(input);        PdfSaveOptions saveOptions = new PdfSaveOptions();        saveOptions.setCompliance(PdfCompliance.PDF_A_1_B);        ByteArrayOutputStream pdfDocument = new ByteArrayOutputStream();        workbook.save(pdfDocument, saveOptions);        return pdfDocument.toByteArray();    };}

代码:WordPDFConverter.java

代码语言:javascript
复制
/** * This class holds the algorithm for converting WORD  * documents to PDF. * @author Hussein * */public class WordPDFConverter implements Converter {    @Override    public byte[] convertToPDF(byte[] fileBytes) throws Exception {        InputStream input = new ByteArrayInputStream(fileBytes);        com.aspose.words.Document wordDocument = new com.aspose.words.Document(input);        ByteArrayOutputStream pdfDocument = new ByteArrayOutputStream();        wordDocument.save(pdfDocument, SaveFormat.PDF);        return pdfDocument.toByteArray();    }}

代码:PDFConverter.java

代码语言:javascript
复制
public class PDFConverter {    /**     * This method accepts as input the document to be converted and      * returns the converted one.     * @param fileBytes     * @throws Exception      */    public byte[] convertToPDF(Converter converter, byte[] fileBytes) throws Exception    {        return converter.convertToPDF(fileBytes);    }}

当调用convertToPDF()时,我们强制用户决定应该使用哪种转换算法。

2. 这样做的好处是什么?!

  1. 关注点分离(高内聚/低耦合): 现在 PDFConverter 类对程序中使用的转换算法一无所知,它主要关注的是为用户提供各种转换特性,而关心转换是如何进行的。现在,我们可以随时替换底层转换框架,只要我们能够返回预期的结果,就不会人会知道。
  2. 单一职责: 创建抽象层并将每个动态行为移到单独的类之后,我们实际上删除了 convertToPDF() 方法在以前初始设计中的的多重职责,现在它只有一个职责,就是将用户的请求委托给抽象的转换层。此外,转换器接口的每个实现类现在都有一个单一的责任,即将某些文档类型转换为PDF。因此,每个组件都有一个被修改的理由,因此没有回归。
  3. 打开/关闭程序: 我们的程序现在对扩展开放,并且对修改关闭,当我们在未来想要支持一些新的文档类型时,只需要从 Converter 接口创建一个新的实现类,并且不需要修改 PDFConverter 工具,因为现在我们的工具依赖于抽象。

3. 从这篇文章中学到的设计原则

以下是构建应用程序架构时要遵循的最佳设计实践:

  1. 将程序划分为几个模块,并在每个模块的顶部添加一个抽象层。
  2. 有利于抽象实现:一定要依赖抽象层,这将有利于程序将来的扩展,抽象应该应用于程序的动态部分(最有可能经常改变的部分),不一定在所有的部分,因为在过度使用的情况下是你的代码变得非常复杂。
  3. 确定程序的不同方面,并将它们与保持不变的部分分开。
  4. 不要重复自己:永远把重复的功能在一些工具类中,并使其通过整个程序访问,这会使你的修改变得容易得多。
  5. 通过抽象层隐藏低级实现:低级模块有很高的可能性会定期更改,因此将其与高级模块分开。
  6. 每个类/方法/模块应该有一个理由去改变,所以为了减少回归,总是给每一个类单一的责任。
  7. 关注点分离:每个模块都知道其他模块做什么,但是它自己不知道该怎么做。

作者简介: HUSSEINTEREK: programmergate.com的创始人,对软件工程和所有与java相关的东西都充满激情。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-08-02,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 京程一灯 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1. 一个实际的场景
    • 需求总是变化
      • 正确的方式
      • 2. 这样做的好处是什么?!
      • 3. 从这篇文章中学到的设计原则
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档