首页 > 行业资讯 > 资讯动态

抽象，简化和领域驱动设计

日期：2024-04-23 　作者：小天　来源：www.txunda.com 　人气：37

图片部分出自由Sudharsan Ravichandiran所著的《Hands-On Reinforcement Learning with Python》是一本实战性的强化学习书籍，重点讨论了强化学习任务的递推方法，一类是系统不断地运行，一类是有终态的系统，还有一类是有终态的，这两类都是不相关的。他们每个都有自己的回退功能；但因为在这两个场合都有大量的讨论；因此，作者将可结束的类型看成是一个永远不会结束，但从结束状态开始，向后返回的次数为0。这样一来，“两类不必区别”的问题就容易多了；
借这个例子想说几点:
首先，抽象无处不在，这并不是说你掌握了几种实现抽象的方法，掌握了几种编程语言的特征，掌握了多少设计模式，就像你学到了再多的绘画技巧，也不可能学会绘画；抽象的运用到处都是，比如讨论问题、写作、演讲等。
其次，抽象需要成本，需要长时间的投入，而将两种强化学习的重复计算统一在一起，就很难理解两者（例如：对于不懂抽象背景的人来说，用一个可终止类型来表示一个可终止类型，会感到很怪异，因为这个公式的深度是无限的，除非读者在结束状态后回退为0，否则就会明白，这和删除结束后的所有运算是一样的，但总感觉怪怪的）；我们的投入一定要有回报，而且回报一定要比投入更大，换句话说，抽象的复杂性会让整个系统的复杂性降低到一定程度。以退为进，收拳是为了发力，虚是为了化繁为简；另外，这种抽象是很差的；一个系统，究竟是变得更加简单，还是变得更加复杂，才是验证其正确性的唯一标准；

但难就难在，每个人都有自己的标准，比如一个数学家，他可能会认为一个数学符号是一种很自然的东西，比一篇长篇大论的文章要准确、简洁、易懂，但对于一般人来说，却是一种晦涩难懂的东西。又比如，抽象可以降低编程的复杂性，但前提是用户要理解这种抽象，才能将其应用到实际中。对阅读者而言，究竟是一篇简洁却又非常抽象的程序，还是一篇结构类似的“重复”，逻辑上更容易理解，那就要看读者自己的能力了。

天津天迅达科技有限公司

如果您需要相关服务，可以找天津天迅达科技有限公司，我们的业务有Web开发、iOS APP、Android APP、微信开发、HTML5开发等，天迅达——您身边的App个性化定制专家！

领域驱动设计对于业务抽象和实现应该遵循怎样的原则给出了答案；即：业务逻辑的抽象和实现应紧密结合于领域语言，这个语言里的名词应该是任何非技术人员都能理解的概念，这个语言里的动词应该是任何非技术人员都能理解的系统行为；任何的业务抽象，都应该是和此业务的专家讨论决定，抽象能否极大的简化和业务专家或者业务人员的讨论是抽象是否成功的关键，这也就是DDD里distill domain model的过程；我们所精炼的语言就是领域模型的精炼抽象，它应该大大的简化我们的讨论（比如当我们发现大家总是在讨论中搞混几个概念，那么肯定有一个或者几个概念存在歧义，这就是把一个词或概念清晰的redefine为多个清晰概念的好时机，而如果我们发现我们的语言很啰嗦，总是需要重复类似的东西，那么就说明这里可以抽象出一个让表达更简洁的概念出来）；
没有什么书或人可以教会你抽象的能力，就好比Lamport在Specifying System一书中所说: “写一个Spec最难的地方是选择合适的抽象, 我(lamport)可以教你怎么写TLA+，但是我无法教会你怎么做抽象, 好的工程师懂得如何把系统最精髓的地方抽象出来而淡化不重要的细节，抽象的艺术只能通过经验获得;”
磨练自己从实际问题中获得的分析能力，抽象能力，使得自己可以快速理解业务和抽象出精炼的业务模型来简化讨论/设计/实现，这是一门无法去教也无法去学的艺术；也是程序员的核心竞争力之一。我也无法告诉你如何学好抽象，但是我知道很多阻碍自己提高自己抽象能力的例子；比如自我限制的去把工作分成业务的和技术的，认为业务应该由PM全权负责，自己的职责只在技术范畴；往往是阻止年轻程序员成长的最大阻碍（对于所谓"算法/工程"之分也是如此）；对于任何工作“做出来就好”，而不去进一步思考是否可以简化实现，过度抽象了之后是否反而造成了理解障碍，也是阻碍抽象能力成长的阻力之一；

学会抽象的艺术，也许就在于一段程序用10种方法反复实现了之后才选出满意的一种提交code的初心吧。

以上所有设计图和部分文字均来自网络，如有侵权，请call我删除，感谢~

天津天迅达科技有限公司经过多年来对APP、小程序、以及网站建设的探索，已经帮助每一个客户快速开发出属于自己的APP、小程序、网站，是万千企业之选。

标签：天迅达科技天津APP开发天津网站建设网站建设