Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

不,这样的 DTO!

Posted on 09/11/201110/08/2024 by 四火

R.Martin 本文翻译自 Oh No! DTO! by Robert C. Martin,这篇文章很短,强调的内容简单得不能再简单,也许大家早就意识到,但是,我依然可以在很多产品的代码里面找到文中所说的 “教条” 的影子,我说不清为什么,在这里有激烈的讨论,你们说呢?

 

本周我在教授 XP(极限编程,译注)的课程,我们要写给当前的应用写 FitNesse(一种测试工具,译注)的基础测试代码。其中一位程序员使用了 RowFixture(一种测试结果比较的工具,译注),这种工具需要使用 DTO(数据传输对象)并且要求其中的变量都为公有的。这时候这位程序员提出了质疑:“DTO 应该使用私有的变量和一套相应的 getter、setter 方法!”,“为什么呢?” 我问。

 

到底是为什么?面向对象的信仰如此根深蒂固地影响我们,以至于我们都无法识别出来,这里根本就只是一个数据结构吗?为什么我们要用一堆毫无用处的 getter、setter 方法,去遵循那些没有人可以解释的通的教条,来膨胀我们的代码呢?

 

在我的观点中,面向对象程序包含两种实体:对象和数据结构。对象有私有属性和公有方法,数据结构只有公有属性并且没有方法(或者只有一些毫无意义的数据访问方法)。有很好的理由去保持变量的私有性,我们想知道是什么方法在操纵它们,我们可以保护对象的数据,我们不想让其它人依赖对象内部的细节,即 DIP(依赖倒转原则,Dependency Inversion Principle,即要依赖于抽象,不依赖于具体,译注)。但另一方面,对一个单纯的数据结构使用 getter 和 setter 并没有什么好处,一个数据结构只是一种数据简单的容器,没别的了!

 

—————————————————————————————————————-

 

2012-2-22,以下补充内容译自 The C++ Style Sweet Spot by Bjarne Stroustrup:

 

 

我尤其不喜欢一个类里面有一大堆 getter、setter 方法,这通常意味着这个类一开始就不该是一个类,这个东西只是个数据结构。既然它是数据结构,就让它成为数据结构好了。

 

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. Lombok 介绍
  2. 重新发明轮子
  3. API 风云录
  4. 对象转换的问题
  5. 追求纯粹

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 聊一聊分布式系统中的时间
  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • Ticket: TRANSACTION 1.922915 BTC. Go to withdrawal >> https://yandex.com/poll/enter/BXidu5Ewa8hnAFoFznqSi9?hs=20bd550f65c6e03103876b28cabc4da6& on 倔强的程序员
  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme