软件设计原则

布满荆棘的人生 2022-06-09 23:51 259阅读 0赞

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

说明：本文首发于公众号：yidengxuetang

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

## 1. 一个实际的场景 ##

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

代码：PDFConverter.java

/** * 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

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

/** * 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

/** * 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

/** * 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

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相关的东西都充满激情。

--------------------

欢迎扫描二维码关注公众号，每天第一时间推送我翻译的国外最新技术文章。

![SouthEast][]

[http_programmergate.com_software-design-principles]: http://programmergate.com/software-design-principles/
[SouthEast]: /images/20220610/db3a914a578a4b97bce6730ba0634fb2.png