过程式/面向对象。 对象和数据结构。横向扩展纵向扩展的对立关系

[petelin]

在读代码整洁之道的时候，看到了一个非常牛逼的观点。用我的理解诠释一下。

横向扩展： 加一个类似的需求，比如登录功能需要加新增一种登录方式

纵向扩展： 对现在已有的功能，进行延伸，加固，比如 [所有] 登录功能都加一个验证码，都做一下限流。。（没想到更合适的需求）

这里然我震惊的一个事实是，过程式也是有好处的，这也是为什么过程式很容易被写出来，一个不精心设计的代码，在扩展总是用过程式的方式去演进。等到之后需要横向扩展的时候就凉凉了，需要在所有的地方都进行修改。而面向对象的编程在面向横向扩展的需求的时候，非常开心，因为每次横向扩展都只需要按模子去把方法实现了就可以了。但是横向扩展需要重构，需要设计，否则编码起来就像是在重复搬砖。通用性会很低。很容易写散

在描述一下代码的两种状态。

• 新新手 /刚起步的代码喜欢用过程式代码，因为修改起来非常方便，一个 switch case 打天下。逻辑还不够复杂。横向扩展就找到所有用到的地方去修改一下~ 之后有一天需要横向扩展，来一个需求之后发现，无法遍历所有需要修改的地方了。。。本质上是系统耦合度太高，所有东西都搞在一起乱糟糟的。
• 等到后期，面对 shi 一样的代码，老油条会竭尽全力避免修改之前的代码，做横向扩展。什么需求都想要单独来一套，然后会发现和之前业务重叠的地方，之后又小需求变更（纵向延伸），两个地方都要改。也痛苦的要死。本质上是因为内聚性不够了，横向扩展的没有通用性~

[petelin]

ps： 其实上面说的都不绝对。对于过程式也可以有很好的抽象。面向对象也可以写散。 改的时候都大动干戈。 对于 shi 山来说，往往两种都有， 一边 switch case， 一边搞出来独立的一套。 其实两面不讨好。 究其原因没有高屋建瓴的结构，没有良好的抽象。那种写法都拯救不了。。

[lovedebug]

微服务化之后横向扩展会容易，但是要求架构设计时能预估到热点，做比较彻底的垂直切分和水平切分。
个人感觉微服务化之后很多单体中的难以扩展问题，其实转化成了架构设计问题，依赖于中间件和队列等，相对会容易解决

[secondwtq]

Expression Problem 了解一下

[xuanbg]

C 语言没有对象，屎山代码反而少。造成代码失控的根本原因是没有设计，没有设计也就不可能有合理的代码组织和结构。就像一团纠缠在一起的线团，根本就解不开，于是只好再胡乱缠上几圈拉倒。

[petelin]

@secondwtq 感谢。完全就是这个问题。 因为没有在工作中写过纯面向对象的代码。所以对理解，加一个函数为什么不去改原来的类，而是要扩展一个新类还没有付出过代价的认知。。。