【软考论文】论面向对象设计方法及应用

本文以该项目建设为例，讨论了了面向对象设计方法中的几个关键设计原则，包括单一职责原则、开放封闭原则、里氏替换原则、接口隔离原则、依赖倒置原则等、以及在本系统中的具体应用以及遇到的问题和解决方案。项目于2021年11月顺利通过验收上线运行，已稳定运行2年多的时间，获得用户一致好评。

摘要

2021年初，我所在的研发部承担了公司自研XXXX管理平台项目的建设，为客户公司提供一站式的股权管理服务。我在该项目中中承担架构设计师的职务，主要负责该项目的系统架构、技术方案评估与实现、项目立项论证等工作。平台为上市公司提供资金管理、财富管理、税务服务等一站式XXXX相关服务的支持，涵盖股权管理、估值管理、多样化激励方案信息化管理、税务与财务咨询服务及系统个性化定制服务等。

本文以该项目建设为例，讨论了了面向对象设计方法中的几个关键设计原则，包括单一职责原则、开放封闭原则、里氏替换原则、接口隔离原则、依赖倒置原则等、以及在本系统中的具体应用以及遇到的问题和解决方案。项目于2021年11月顺利通过验收上线运行，已稳定运行2年多的时间，获得用户一致好评。

正文

国务院发布的《关于支持浙江高质量发展建设共同富裕示范区的意见》中提到了浙江到2025年和2035年要实现的共同富裕相关目标。越来越多的上市企业选择对员工开展XXXX计划。我所在的某集团公司，为了集团的发展，需要在XXXX相关服务这一赛道上保持竞争力，根据这一目标，XXXX管理平台这一项目应运而生。2021年初，我所在的研发部承担了公司自研XXXX管理平台项目的建设，为客户公司提供一站式的股权管理服务。我在该项目中中承担架构设计师的职务，主要负责该项目的系统架构、技术方案评估与实现、项目立项论证等工作。整个平台为上市公司提供资金管理、财富管理、税务服务等一站式XXXX相关服务的支持，涵盖股权管理、估值管理、多样化激励方案信息化管理、税务与财务咨询服务及系统个性化定制服务等，更高效、更便捷地为企业客户提供“一篮子”金融解决方案。整个平台涉及证券、税务、银行、电子签署等过个复杂业务逻辑，业务流程复杂、系统可靠性和可扩展性要求较高，影像的范围比较广。整个平台以多租户的模式，进行统一的管理及日常运营，通过组织机构管理提供给上市公司进行业务的管理和服务。

面向对象设计方法强调以下常见的设计原则：单一职责原则（SRP）：每个类应该只有一个引起变化的原因，每个类都应该负责一个明确的职责，并且这个职责应该被完全封装在类内部。当一个类承担了多个职责时，这些职责可能会相互干扰，导致代码难以维护。开放封闭原则（OCP）：软件实体应该可以扩展，但不可修改，这意味着当需求发生变化时，我们应该尽量通过扩展现有代码来实现新功能，而不是修改已经存在的代码。这样可以降低系统的复杂性，提高代码的可维护性。里氏替换原则（LSP）：子类必须能够替换其父类且软件单位的功能不受影响。这要求子类必须严格遵循父类的行为约定，确保在替换父类时不会破坏系统的正确性。依赖倒置原则（DIP）：高层模块不应该依赖低层模块，两者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。这要求我们在设计系统时，将具体实现与抽象接口分离，通过接口进行交互。这样可以降低系统的耦合度，提高代码的可扩展性和可维护性。接口隔离原则（ISP）：我们应该将接口拆分成多个更小的、更具体的接口，以便客户端只需要实现它们真正需要的接口。这可以降低系统的耦合度，提高代码的可重用性。

在XXXX管理平台项目中，我充分运用了面向对象设计方法的思想和原则来开发系统。下面我将结合项目实际来阐述如何应用面向对象设计方法。

我们深入分析了该系统的核心需求，并根据这些需求将整个系统进行了业务拆分。原则是确保不同服务的业务边界明确、避免重复开发相同的业务功能，这也符合单一职责原则的要求。我们将整个系统拆分成了六个独立的服务：用户权限管理服务、XXXX管理服务、资金归集服务、税务缴纳服务、电子签署服务、消息推送服务。在类设计过程中，我们也确保每个类只负责一个功能域中的相关职责。例如我们创建了“激励计划类”来管理XXXX计划的逻辑，创建了“行权解禁类”来处理参与方行权解禁的逻辑，创建了“参与方类”来管理激励计划参与方的信息等。这些类各自承担了一个明确的职责，并且与其他类之间的耦合度较低。同时，我们也考虑了系统的扩展性，为可能出现的需求变化预留了空间。

通过策略模式和依赖倒置原则的应用，我们成功构建了一个灵活且易于扩展的资金归集服务。策略模式也符合开闭原则。在服务层的开发过程中，我们意识到不同的业务类型往往需要不同的处理策略。因此，我们采取了一种差异化的方法，根据业务的特点和需求，选择最合适的涉及方法来处理。例如，在资金归集模块，我们的系统需要和银行的查询接口对接，来获取激励计划归集资金的金额，并确认激励计划参与方资金缴纳的状态。我们考虑到了未来可能需要与多个不同银行的系统集成的需求，为了确保系统的灵活性和可扩展性，我们选择了策略模式来实现这一部分的功能。我们首先设计了一个BankService接口，接口中定义了查询资金归集信息方法，然后又针对我们系统要对接的招商银行和北京银行分别实现了相应的实现类MerchantsBankServiceBean和BeiJingBankServiceBean ，最后我们还定义了一个BankServiceFactory的工厂类，在工厂类中依赖BankService接口来管理不同银行的对接接口，而不是依赖于具体的实现类。这样就允许我们在运行时动态地选择算法或方法，如果未来我们需要对接新的银行接口或者某个银行接口需要修改，就可以轻松地添加新的银行实现类，而不会影响其它银行的对接逻辑。这种设计方法不仅降低了维护成本，而且提高了系统的可维护性和可扩展性，符合开放封闭原则。

另外，我们在项目中引入了消息队列实现了服务之间的解耦，这也符合迪米特最小知识原则的设计。在激励计划执行过程中，公司会给员工推送激励计划执行的相关消息通知，在最初的设计中，我们是在XXXX模块的服务直接调用消息推送的接口来进行消息推送，消息推送逻辑是同步进行的，也就是XXXX服务会等待消息推送接口返回响应后再进行后续的业务处理。在系统测试过程中，我们发现当批量的给大量的员工推送消息时，这个过程会比较耗时，前台页面会等待较长的时间才能得到响应。为了解决此问题，我们引入了消息队列技术。XXXX服务将要推送的消息信息发送到消息队列中，然后消息推送服务从消息队列中不断地拉取信息进行消息推送。通过使用消息队列，我们将耗时的消息推送操作进行了异步处理，XXXX服务不再需要等待消息推送服务的处理结果就可以继续处理其它业务逻辑，实现了XXXX服务和消息推送服务之间的解耦，避免了两个模块之间的直接依赖，不仅提高了系统的独立性和可扩展性，也显著提高了系统的响应速度和用户体验，

2021年11月，XXXX管理系统正式上线运行，至今已经稳定地运行了超过两年的时间，期间不仅顺利应对了访问量激增的挑战，例如某个客户公司员工约5000人，在公司发起与员工进行电子协议签署后，由于大量员工同时进行线上签署，导致签署服务由于负载过高而全部宕机。还成功处理了紧急情况下客户公司的接入需求，这些都是对我们运维能力的巨大考验。面向对象设计方法是一种强大的工具，它可以帮助我们构建高质量、可扩展、可维护的软件系统。通过遵循设计原则并将其应用于实际项目中，我们可以提高代码的可读性、可维护性和可扩展性，同时降低开发风险。在未来的软件开发中，我们将继续深入研究和应用面向对象设计方法，以应对更加复杂和多样化的业务需求。