1.面向对象优点和缺点有哪些，哪些场合不适合面向对象？

面向对象的优点：

• 符合人类的思维习惯：传统的结构化软件开发方法是面向过程的，以算法为核心，数据和过程作为相互独立的部分，数据和过程分离，忽略了数据和操作之间的内在的联系。面向对象的方法是以对象为核心，尽可能接近人类习惯的抽象思维方法，并尽量一致地描述问题空间和解空间。

• 稳定性高：面向对象方法用对象模拟问题域中的实体，以对象间的联系刻画实体间联系。当系统的功能需求变化时，仅需做一些局部的修改，不会引起软件结构的整体变化。现实世界中的实体是相对稳定的，以对象为中心构造的软件系统也会比较稳定。

• 重用性好：面向对象方法具有的继承性和封装性，支持软件复用。有两种方法可以重复使用一个对象，一是创建类的实例，从而直接使用它；二是从它派生出一个满足需要的新类，子类可以重用其父类的数据结构和程序代码，并且可以在父类的基础上方便地修改和扩充，而且子类的修改并不影响父类的使用。

面向对象的缺点：

• 如果场景简单，反而增加代码复杂度。
• 继承的特性使得子类和父类紧耦合。
• 面向对象使用不当时会造成过度设计。

不适合用面向对象的场景：

• 处理大量的数据集合：关系型数据库以表为单位存储数据，无法对应上“对象”的概念，用SQL处理数据最简单直接。
• 并行计算：并行计算是指同时使用多个计算资源来解决一个计算问题：一个问题被分解成为一系列可以并发执行的离散部分；每个部分可以进一步被分解成为一系列离散指令；来自每个部分的指令可以在不同的处理器上被同时执行。面向对象这种思维模型完全不适合并行计算的场景。

2.软件设计领域有哪些设计模式？

https://www.runoob.com/design-pattern/design-pattern-intro.html

3.你常用哪几种设计模式，适应哪些场景，优缺点是什么？

• 单例模式：单例模式用来创建全局唯一的对象。一个类只允许创建一个对象（或者叫实例），提供一个访问它的全局访问点，常常用于文件系统、打印程序等。
• 工厂模式：工厂模式包括简单工厂、工厂方法、抽象工厂这3种细分模式。其中，简单工厂和工厂方法比较常用，抽象工厂的应用场景比较特殊，所以很少用到。工厂模式一个非常经典的应用场景：依赖注入框架，比如Spring IOC，它用来集中创建、组装、管理对象，跟具体业务代码解耦，让程序员聚焦在业务代码的开发上。
• 策略模式：策略模式定义多个算法类，将每个算法分别封装起来，让它们可以互相替换。最常见的应用场景是，利用它来避免冗长的if-else或switch分支判断。策略模式主要的作用还是解耦策略的定义、创建和使用，控制代码的复杂度，让每个部分都不至于过于复杂、代码量过多。

4.公司级应用有哪些特别要求？

• 应用安全：确保应用设计、开发、部署、升级或维护中的不出现重大漏洞。即使出现了，也要在可容忍的时间内尽快解决。
• 应用合规：产品本身是否合规，对用户隐私的收集是否合规。
• 可扩展性：快速扩容满足业务发展的需求。
• 高可用性：尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。通常用N个9来形容可用性，比如99.99%。
• 设备兼容性：如果是Web应用或者手机APP，要考虑设备兼容性，达到用户体验的一致性。
• 可监控性：网络健康和系统性能监控、调用链日志采集。

5.怎么进行子系统划分?

1. 把系统划分为一些模块，其中每个模块的功能简单，明确，内容简明易懂，任务清楚明确，以便易于修改。
2. 每个模块要比较小，每一项任务限制在尽可能少的模块中完成，最好是一个模块来完成，这样就可以避免修改时遗漏应修改的地方。
3. 系统分成模块的工作按层次进行。首先，把整个系统看成一个模块，按功能分解成若干个第一层模块，这些模块互相配合，共同完成整个系统的功能。然后按功能再分解第一层的各个模块。依次下去，直到每个模块都十分简单。
4. 每一个模块应尽可能独立，模块之间的联系及互相影响尽可能地减少，尽可能减少模块间的调用关系和数据交换关系。当然，系统中模块不可能与其他模块设有联系，只是要求这种联系尽可能少。
5. 模块间的关系要阐明，在修改时可以追踪和控制。
6. 模块所包含的各个过程之间内在联系应尽可能强。
7. 模块的划分应便于总的系统设计阶段实现。

6.你如何看待服务化，什么样的业务需要做服务化？

服务化是指把一个系统中的各个业务进行抽象分离以后，以服务为单位进行开发和管理。复杂的单体应用拆分为多个可以独立部署的服务，单个服务的复杂性远远小于整体，这样不同服务的开发者可以并行开发，从而提高开发效率。服务化的优点：

• 低耦合：将相同业务领域的功能拆分为独立的服务，避免与其他模块过度耦合。
• 服务可复用：将常用的高频模块服务化，有效提供复用度。
• 隔离故障：每个服务独立运行，自身出现故障不会影响其他服务，但是被上层依赖的服务要做好降级和熔断。
• 快速迭代和独立发布：以服务的纬度进行开发和发布，不干扰其他业务的开展。

服务化的一些缺点：

• 架构更为复杂：服务和服务之间调用，要考虑到网络抖动、负载均衡、服务监控等问题，需要引入很多工具进行治理，大大增加了架构的复杂性。
• 运维更加困难：拆分服务会显著增加服务的数量，系统日志变得更多，查找日志也变困难，大大加重运维的负担。

服务化的优势是相对单体架构的。如果功能都集中在一个单体应用上，这个应用将拥有太多的功能，就会造成代码过多、维护、迭代、发布也会变得困难，这时候需要做服务化。

6.微服务与SOA的区别，请比较构建微服务的常见方案？
SOA是一种面向服务的架构 ，基于分布式架构 ，它将不同业务功能按服务进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。
SOA的特点：

1. 将重复公用的功能抽取为组件，以服务的方式向各各系统提供服务。
2. 各各系统与服务之间采用webservice、RPC等方式进行通信。
3. ESB企业服务总线作为系统与服务之间通信的桥梁。

SOA的优点：

1. 将重复的功能抽取为服务,提高开发效率 ，提高系统的可重用性、可维护性。
2. 可以针对不同服务的特点按需伸缩。
3. 采用ESB减少系统中的接口耦合。

SOA的缺点：

1. 系统与服务的界限模糊，会导致抽取的服务的粒度过大，系统与服务之间耦合性高。
2. 虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。

基于SOA架构的思想，对服务层进行细粒度的拆分，每个服务只完成特定的业务功能，比如订单服务只实现订单相关的业务，用户服务实现用户相关的业务。服务的粒度很小，所以称为微服务架构。

微服务特点：

1. 服务层按业务拆分为一个一个的微服务。
2. 微服务的职责单一。
3. 微服务之间采用RESTful、RPC等轻量级协议传输。
4. 有利于采用前后端分离架构。

微服务优点：

1. 服务拆分粒度更细，有利于资源重复利用 ，提高开发效率。
2. 更加精准的制定每个服务的优化方案 ，按需伸缩。
3. 适用于互联网时代，产品迭代周期更短。

微服务缺点：

1. 开发的复杂性增加，一个业务流程需要多个微服务交互来完成。
2. 微服务过多，服务治理成本高。

参考(摘抄的文字版权属于原作者)
https://blog.csdn.net/fishmai/article/details/52079766
https://blog.csdn.net/weixin_45139605/article/details/90796758
https://www.zhihu.com/question/20275578?sort=created
https://www.runoob.com/design-pattern/design-pattern-intro.html
https://blog.csdn.net/weixin_45525272/article/details/123552570

本文链接：https://www.codingbrick.com/archives/704.html
特别声明：除特别标注，本站文章均为原创，转载请注明作者和出处倾城架构，请勿用于任何商业用途。