抽象如何助力DRY原则？维基百科DRY定义中抽象含义解析

嘿，这个问题问得特别到位，刚好戳中了很多开发者刚开始接触DRY和抽象时的困惑点，我来给你一步步理清楚：

一、抽象到底是怎么帮我们落地DRY原则的？ #

DRY的核心就是绝对避免重复的逻辑、代码或模式，而抽象就是实现这个目标最核心的工具——它的本质是把重复出现的“共性”提炼出来，变成一个可复用的单元，让所有需要这个逻辑的地方都去调用它，而不是重复写一遍。

咱举几个接地气的例子：

• 最基础的函数抽象：比如你在电商系统的订单页、购物车页、结算页都要计算用户的会员折扣，每次都写price * memberDiscountRate的代码，这就违反了DRY。把这段逻辑封装成calculateMemberDiscount(originalPrice)函数，以后所有页面都调用这个函数，不仅消除了重复代码，哪天要改折扣规则（比如新增等级折扣），只需要改这一个函数就行，不用到处找重复的代码修改。
• 类/接口抽象：如果你的系统里有“普通用户”“VIP用户”“企业用户”三种角色，他们都需要发送消息通知，但通知的模板和渠道不一样。这时候你可以抽象出一个UserNotifier基类，把通用的通知逻辑（比如记录通知日志、重试机制）放在基类里，三种用户的通知类只需要实现自己特有的模板和渠道逻辑就行——这样通用逻辑就不用重复写三遍了。
• 架构层的抽象：比如你一开始用MySQL存储数据，后来想换成MongoDB，如果业务代码里直接写SQL语句，换库的时候要改几百处代码。但如果抽象出一个DataAccessLayer（数据访问层），业务代码只调用这个层的getUserById()、saveOrder()等方法，具体的SQL或MongoDB操作都封装在这个层里，换库只需要修改数据访问层的实现——这从根源上避免了重复的数据库操作逻辑，完美贴合DRY。

总结下来：抽象就是帮我们把“重复的劳动”变成“一次封装，多次复用”，从根本上消除冗余，这正是DRY原则要实现的目标。

二、维基百科里的"abstractions"和你认知的区别 #

你理解的“隐藏API行为实现的复杂度”其实是抽象的一种具体表现（也就是封装），但维基百科里提到的abstractions是更广义的概念——它指的是任何能替换重复模式的复用单元，不仅仅是API层面的封装。

举个例子帮你区分清楚：

• 你认知的抽象：比如调用HashMap.put()的时候，你不需要知道它底层是怎么处理哈希冲突、怎么扩容的，只需要知道它能存键值对——这是封装型抽象，核心是隐藏实现细节，让调用者不用关心底层。
• 维基百科里的abstractions：除了上面的，还包括我们前面说的函数抽象、类抽象、甚至是设计模式（比如用单例模式避免重复创建同一个实例，用工厂模式避免重复的对象创建逻辑），甚至是架构层面的组件（比如微服务里的网关抽象，统一处理认证、限流）。本质上，只要是能把重复的代码、逻辑、模式提炼成可复用的东西，都属于这里说的abstractions。

维基百科那句话里的“replacing them with abstractions”，意思就是把那些重复出现的软件模式（比如重复的计算逻辑、重复的业务流程、重复的对象创建逻辑），替换成各种形式的抽象单元——不管是函数、类、接口，还是架构组件，只要能消除重复、实现复用，就是这里的abstractions。

说白了，你之前的认知是抽象的一个子集，而维基百科里的是抽象的全貌。

内容的提问来源于stack exchange，提问作者zero_yu