跳至主要內容

(1)基础知识


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

面向对象的优点:

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

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

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

面向对象的缺点:

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

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

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

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

https://www.runoob.com/design-pattern/design-pattern-intro.htmlopen in new window

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/52079766open in new window
https://blog.csdn.net/weixin_45139605/article/details/90796758open in new window
https://www.zhihu.com/question/20275578?sort=createdopen in new window
https://www.runoob.com/design-pattern/design-pattern-intro.htmlopen in new window
https://blog.csdn.net/weixin_45525272/article/details/123552570open in new window

上次编辑于: