这是我在观察过程中的想法（无论好坏）的备忘录。一年后为我自己！
这是一首重新思考我想说的话的诗。
概述
- 故意不想接触函数类型
- 普遍承认对继承和可重用性的怀疑
- 补充抽象策略开发策略
- 标题是钓鱼
- 抽象词的浮动意义
- 封装问题
我故意不想接触函数式语言
多态的故事里有很多人指出函数类型，但我不想直接接触。这是因为我不希望它是面向对象与功能性的。 （结果，Rust/Go 被击中）
原因是面向对象的下降（结果）是开发方式的变化我们认识到，提炼设计理论是主轴。
在适应不确定性方面，我认为通过继承和封装来隐藏状态的策略效果不佳，改为面向对象。这是因为变化的方法融合了函数式编程的本质，不同于简单的对抗-歼灭关系。
我已经将您与抽象混淆了，但我相信通过接口的松散耦合对最近的应用程序架构产生了重大影响。
对继承性和可重用性怀疑的共同认识
我觉得我在这里重复自己。似乎没有强烈的迹象，这是一种普遍的认识。这就是它的感觉。我想从滥用抽象的角度把这篇文章再走两步，但是最后一步没有奏效。 .
步骤 1 对可重用性的怀疑
第二步 足够谈论开发设计策略
步骤 3 松开面向对象抽象的轮廓
谈够了开发设计策略
第二步。足够的开发设计策略。
“它不一定是面向对象的编程。”
这是为该领域的开发人员准备的，对吧？我觉得你认同我的感受。
因为具体的代码示例比较薄弱，所以有些地方难以传达。我也觉得通过补充评论能够掌握意图。
总之，我想说的是
而不是像 IdProvider 那样抽象硬轮廓......
重要的是派生出变化少、独立性高的函数，比如GoogleProvider、OidcProcess。相反，对于像组合一样变化的部分，您只需要跟随变化即可。自动测试可以充分保证安全。
（混合）当然，代码的安全性较低。但是，如果您错过了抽象，这比增加的变更风险要好。 （只是经验）
此外，我们需要减少自动化测试的依赖关系，并且我们需要接口。
当时觉得interface GoogleProvider比interface IdProvider好。标题是钓鱼
是的 是的 钓鱼 钓鱼。相反，我相信面向对象编程正处于衰落的边缘。我觉得应该考虑使用具有强烈影响力的标题，因为考虑到它的话题性，它很容易传播到广泛的区域。
图像线是“对象方向融合并消失为对象方向”。
这就是为什么我想在情感上结束它。我也那么认为。
结果，抽象这个词就被牺牲了。抽象这个词的蓬松感
抽象不是抽象的。
步骤 3 松开面向对象抽象的轮廓
与其否认抽象，我想说的是“面向对象的抽象”已经失去了它的轮廓，很局促，但是哦，好吧。 . .我在写的时候就知道这不好。 .我还是无法解释。我自己似乎无法理解这一点。
所以，这是一首重新思考的诗
封装不良
步骤 3 重新考虑 另一个咆哮。
你想说什么？
改变的感觉如何？
要解决的对象的抽象和抽象的表达应该是分开的阶段。面向对象编程难道不是一种可以轻松连接抽象和抽象表达式的语言吗？因此，抽象这个词很难使用。
原始设计开发过程的输出应如下所示。
解決対象 => 抽象化 => 抽象表現（准确的说，不知建模是否正确……）
面向对象编程是不是很容易鼓励↓？
解決対象 => 抽象表現(とくに汎化)尤其是
module GoogleProvider倾向于削减到interface IdProvider。
此外，interface IdProvider没有非常干净的轮廓。你为什么使用 Rust/GO 作为对比？
- 具有派生自类型系统的抽象（多态性）
- 脱离类关键字
- 对封装的反思，例如 Rust 所有权
- Something Go 的面向对象反馈与函数式思想，Rust 的直接函数式风格
大约？
离谱。为什么 OOP 的抽象如此之快？封装不好？
再想一想。
基于类的语言从抽象表示（类）开始。类都是关于封装的，这就是驱使我们进行早期抽象的原因？我觉得封装的缺点被低估了，而抽象是目标。
封装问题
坏的一面
- 隐藏状态管理的想法失败
- 难以在适当的地方披露信息
首先，封装的明显问题是aka引用问题，解决方案是不可变的，这破坏了隐藏状态管理的思想。这就是它所说的。
另外，封装无非是信息隐藏，封装有好有坏，但“好”的形象被强烈滥用。
“坏”的一个很好的例子是在 ValueObject 的上下文中过度本地化和不合适的信息披露（这也在上升）。例如，
年齢によるサイトの利用制限がある際に、利用制限の判定メソッドを年齢オブジェクトに生やしてしまう。也许在某个地方有更好的文章。
此外，即使是应该公开的信息也可能被不必要地隐藏起来。这是理解处理流程的一大障碍。如果它简单地表示为输入的输出，通常更容易理解。
后记：我写了关于隐藏不必要信息的文章，因为有一部分引起了我的注意。
面向对象的编程（基于类的）难道不会促进封装并导致不适当的抽象吗？
我想说什么
面向对象编程的抽象表示很差，暂时做成类（最近是接口）。结果，很可能发生不良封装。
解決対象 => 抽象表現(class)不再基于类的语言有类型（数据）和类的选项，需要抽象表达的缓冲。
（或者说，有很多东西不能用课堂的基本语法来表达）解決対象 => 抽象化 => 抽象表現(data/class)尤其是大号。
难道不能用一组数据类型和过程来做到这一点而不强迫它成为一个类吗？他说，如果你需要它，你也可以使用带有部分类型的抽象表达式。你还在上课吗？什么时候。
找出为什么 Go/Rust 在这里放弃课程可能会很有趣。
快速浏览一下，Rust 0.4 删除了 0.2 中实现的类。维基：锈
这似乎是故意背离面向类的面向对象编程。可能的反对意见
这不是OOP语言问题，可能只是个人设计能力的差异。
=> 如果它不是基于类的语言，它可能会有所不同，因为它会让你注意到？仅仅因为它没有类并不意味着它不是面向对象的
=> 不是吗？可能是类基础应该是主要主题。仅仅因为我们没有类并不意味着我们停止了封装。
=> 不是吗？也许他们只是想停止使用继承策略。也许关键是要清楚地指出除类以外的选项后记
我偶然捡到了它。
“可能的反对意见”部分似乎有一个很好的提示。也许我们应该把注意力转向认知和结构主义，而不是 OOP。https://t.co/i1p6Wdh6z9
— 加藤君 (@j5ik2o)2022 年 8 月 2 日我懂了。也可以从认知的角度来考虑。这是一个离 OOP 不远的故事，但是考虑到 OOP 的心智模型是面向现实世界的，而 FP 的心智模型是面向“数学”的，在 FP 中，抽象（建模）变得必不可少。不管是好是坏，一个垫子是必须的，如果你掌握得好，你可以说抽象的表达并不仓促。
结构主义是一个关键词形象，但很难用语言表达。 .
原创声明：本文系作者授权爱码网发表，未经许可，不得转载;
原文地址：https://www.likecs.com/show-308622222.html