这是一个专门讨论 idea 的地方。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
这是一个创建于 1940 天前的主题，其中的信息可能已经有所发展或是发生改变。
大家都是怎么抽象的，什么情况下运用多态，以及封装的初衷。想请教下大家实际中都是遇到什么场景，以及怎么想到用这些特性的
 |
1
jorneyr 2019-08-09 19:33:40 +08:00
手中无剑
|
 |
2
Iamnotfish 2019-08-09 22:16:27 +08:00
抽象：操作手册，按照上面的来可以知道咋操作的，但是该不会还是不会,因为没有实际操作过；
封装：饭店上好的菜给你，就差喂你吃了； 多态：饭店有宫保鸡丁，宫保虾仁，宫保牛肉，宫保鱼，都是宫保的但是菜不一样。 |
 |
3
tudouxiong 2019-08-09 22:24:55 +08:00 via Android
建议学习下设计模式，感受用法
|
 |
4
akira 2019-08-09 22:40:14 +08:00  1
如果你写过大量的功能相似 但是又有部分细节不一致的代码，你就会开始思考这个问题了。
|
 |
5
charlie21 2019-08-10 00:25:54 +08:00 via iPhone
能不用 OOP 理念就不用，除非逼不得已 要接手别人的 OOP 代码 ...
|
 |
6
Orenoid 2019-08-10 00:36:54 +08:00 via Android
多用组合
|
 |
7
2kCS5c0b0ITXE5k2 2019-08-10 01:09:29 +08:00
这些不都是为了少写些代码...
|
 |
8
siyemiaokube 2019-08-10 01:33:39 +08:00 via iPhone
可以学一些代数学，这些东西都有代数学做支撑
|
 |
9
laike9m 2019-08-10 08:44:21 +08:00 via Android
不要为了多态而多态，为了封装而封装
|
 |
10
qping 2019-08-10 12:21:30 +08:00
目的是适应变化、减少耦合、少写代码
|
 |
11
expkzb 2019-08-10 14:36:28 +08:00
最终目的是为了少写代码，便于人类阅读。
其他自己看着办 |
 |
13
haosamax OP 恩，说下我的情况，第三方的报文有几个相似的节点<Apply></Apply>，但是节点里有两个节点标志这个 Apply 是什么。一开始只是做了个枚举类，用来记录区分，后来对方改了需求，针对不同的 Apply （也就是不同的那两个节点），Apply 里的结构会不同，还有不同的逻辑处理。wdnmd，我都做完了，开始联调了，你跟我说这些。后来想了先之前看过的设计模式，这种场景适用策略模式，百度了下，用枚举可是实现策略模式，具体就是给定一个抽象方法，对于枚举的实例给与不同实现，就完美解决了，对方需求变更我这边不用大改！
|
Select Language