[讨论]关于一个设计方面的问题——主动对象和被动对象中的方法定义

smalldeer 2004-12-07 11:38:13
[讨论]关于一个设计方面的问题——主动对象和被动对象中的方法定义

人 能开车 主动的
车 能开动 被动的

人有开车的能力，但车不能自己开，需要人去开

突然想到个问题，“开”这个方法run()，是写在主动类People中，还是写在被动类Car中
有点疑惑了，以前会习惯性的写在Car这个类中，但现在想想，run这个动作发出者是人，车是被动的，车不能自己动起来，需要人给它这个动作

是不是想太多了，
run如果写在People类中，那Car类怎么样获得方法
run如果写在Car类中，那People中怎么样去触发这个动作

哪种更合适，或有其它更好的处理方法

想法还不是很成熟，请大家指教了

谢谢
...全文
201 21 打赏 收藏 转发到动态 举报
写回复
用AI写文章
21 条回复
切换为时间正序
请发表友善的回复…
发表回复
smalldeer 2004-12-09
  • 打赏
  • 举报
 回复
up
smalldeer 2004-12-08
  • 打赏
  • 举报
 回复
OO方法论的书中：又说，对象的行为(即“做型”责任)可以分为简单行为和复杂行为，前者是对象的内部行为，后者是牵扯到别的对象的行为。

查到了这句话，让我有点想明白了..
smalldeer 2004-12-08
  • 打赏
  • 举报
 回复
oo方法论认为：对象应该自己管理自己的行为。

这个我认同

但应该有点不同，我指主动对象和被动对象的行为

smalldeer 2004-12-08
  • 打赏
  • 举报
 回复
譬如
People的动作走，因为人是自己走的，所以在People中加上walk的方法，很容易明白

车的动作开，实际上是两个行为，先人给车一个动作，再车自己动起来

同样是两个动作，因为是主动类和被动类的不同，导致方法的运转在流程上是不一样的
怎么样更好的解决它们之间的不同？

redex 2004-12-08
  • 打赏
  • 举报
 回复
上面所说好象是DI模式的一种原形。
redex 2004-12-08
  • 打赏
  • 举报
 回复
把Car实现成抽象类，并在People类中保存一个Car类型的引用，在运行时就可以
通过setCar()方法更改不同的Car，这样drive()就可以驾驶不同的Car了。
smalldeer 2004-12-08
  • 打赏
  • 举报
 回复
打字慢了，刚才才只有3个回复

谢谢，继续 ...
redex 2004-12-08
  • 打赏
  • 举报
 回复
另外，可以在People类中加一个drive()方法，当人开车时，就调用
这个方法。在drive()方法中可以调用Car对象的run()方法。
smalldeer 2004-12-08
  • 打赏
  • 举报
 回复
en
谢谢，继续


写在People里，把Cat作为参数传进去，然后调用cat.run()
这是一个组合的应用~

调用方法已经明白了

--------------------------------------------------------------
People类就得写Car如何run了

People类中也不是写Car的run，只是说明People有开的能力,开什么不管，开车的话，传个车的参数进来，它只是开的动作的发出者，开的动作发出给车，然后车的发动机就自己起来了，车运行，如果要转向，也是People发出动作“转向”给车，车才转向。

好比一个轮子，如果不给它任何外力，它是不会滚的，People给它个施加个动作“扔”，轮子才能滚动起来。

宏观的说：有两种类，主动类、被动类
主动类发出动作给被动类，被动类接受动作，然后做出相应的动作

这样的情况在实际中应该是比较多的吧，不知道大家是怎么样处理这样的情况。

处理方法当然有很多了，如果设计的烂一点，那很好解决的。

还是想从中学习到一些东西，请大家指教，谢谢

无欲则钢 2004-12-08
  • 打赏
  • 举报
 回复
"run"方法应该写在car中，people中也有一个run,people的run调用car的run.
redex 2004-12-08
  • 打赏
  • 举报
 回复
oo方法论认为：对象应该自己管理自己的行为。所以，认为run()
这个方法应该放到Car类中。
yellowwee 2004-12-08
  • 打赏
  • 举报
 回复
“run如果写在Car类中，那People中怎么样去触发这个动作”

是呀，由People在需要调用Car.run()的时候调用，这样你需要的People的主动性就体现了
Car如果People不调用，它自己不会run
kaxiou 2004-12-08
  • 打赏
  • 举报
 回复
我觉得是,car的run是一种状态,而不要表示为一种动作,因为car的run是由人来驱动的,
不知道我这种看法是否正确?请高手指点
smalldeer 2004-12-08
  • 打赏
  • 举报
 回复
up
smalldeer1982 2004-12-08
  • 打赏
  • 举报
 回复
继续
chuanyuan88 2004-12-08
  • 打赏
  • 举报
 回复
oo方法论认为：对象应该自己管理自己的行为。

这句话，你仔细理解一下，实际上你的run应该由两部分组成，
一个是人发出 "开车"这个动作，和车"移动"这两个行为。
所以需要做的是，
在people里有一个方法，是run(),这个run是指人能发出开车的动作，不管开的是卡车还是轿车
在car里，这是个具体类，应该有一个move();代表能移动，

所以当我要开卡车的时候，只要把car做为一个参数穿给people的run()，车子就移动了。

这是我个人的理解。
redex 2004-12-07
  • 打赏
  • 举报
 回复
“run如果写在Car类中，那People中怎么样去触发这个动作”

People类中保存一个Car的实例变量和一个方法，在这个方法中
调用Car对象的run()方法。
yellowwee 2004-12-07
  • 打赏
  • 举报
 回复
应该写在Car里好一些，如果写在People中的话，People类就得写Car如何run了，这样就有很高的耦合度！！
还是让Car自己run吧~
yellowwee 2004-12-07
  • 打赏
  • 举报
 回复
写在People里，把Cat作为参数传进去，然后调用cat.run()
这是一个组合的应用~
classjava 2004-12-07
  • 打赏
  • 举报
 回复
呵呵，直接在驾驶这个方法中用了car类的对象做参数这样就用了联系
加载更多回复（1）
领域驱动设计与模式实战
第一部分 背景知识 第1章 应重视的价值，也是对过去几年的沉重反思 1.1 总体价值 1.2 应重视的架构风格 1.2.1 焦点之一：模型 1.2.2 焦点之二：用例 1.2.3 如果重视模型，就可以使用领域模型模式 1.2.4 慎重处理数据库 1.2.5 领域模型与关系数据库之间的阻抗失配 1.2.6 谨慎处理分布式 1.2.7 消息传递很重要 1.3 对过程的各个组成部分的评价 1.3.1 预先架构设计 1.3.2 领域驱动设计 1.3.3 测试驱动开发 1.3.4 重构 1.3.5 选择一种还是选择组合 1.4 持续集成 1.4.1 解决方案（或至少是正确方向上的一大步） 1.4.2 从我的组织汲取的教训 1.4.3 更多信息 1.5 不要忘记运行机制 1.5.1 有关何时需要运行机制的一个例子 1.5.2 运行机制的一些例子 1.5.3 它不仅仅是我们的过错 1.6 小结 第2章 模式起步 2.1 模式概述 2.1.1 为什么要学习模式 2.1.2 在模式方面要注意哪些事情 2.2 设计模式 2.3 架构模式 2.3.1 示例：层 2.3.2 另一个示例：领域模型模式 2.4 针对具体应用程序类型的设计模式 2.5 领域模式 2.6 小结 第3章 TDD与重构 3.1 TDD 3.1.1 TDD流程 3.1.2 演示 3.1.3 设计效果 3.1.4 问题 3.1.5 下一个阶段 3.2 模拟和桩 3.2.1 典型单元测试 3.2.2 声明独立性 3.2.3 处理困难因素 3.2.4 用测试桩替换协作对象 3.2.5 用模拟对象替换协作对象 3.2.6 设计含义 3.2.7 结论 3.2.8 更多信息 3.3 重构 3.4 小结 第二部分 应用DDD 第4章 新的默认架构 4.1 新的默认架构的基础知识 4.1.1 从以数据库为中心过渡到以领域模型为中心 4.1.2 进一步关注DDD 4.1.3 根据DDD进行分层 4.2 轮廓 4.2.1 领域模型示例的问题/特性 4.2.2 逐个处理特性 4.2.3 到目前为止的领域模型 4.3 初次尝试将UI与领域模型挂接 4.3.1 基本目标 4.3.2 简单UI的当前焦点 4.3.3 为客户列出订单 4.3.4 添加订单 4.3.5 刚才我们看到了什么 4.4 另一个维度 4.4.1 领域模型的位置 4.4.2 孤立或共享的实例 4.4.3 有状态或无状态领域模型实例化 4.4.4 领域模型的完整实例化或子集实例化 4.5 小结 第5章 领域驱动设计进阶 5.1 通过简单的TDD实验来精化领域模型 5.1.1 从Order和OrderFactory的创建开始 5.1.2 一些领域逻辑 5.1.3 第二个任务：OrderRepository+OrderNumber 5.1.4 重建持久化的实体：如何从外部设置值 5.1.5 获取订单列表 5.1.6 该到讨论实体的时候了 5.1.7 再次回到流程上来 5.1.8 总览图 5.1.9 建立OrderRepository的伪实现 5.1.10 简单讨论一下保存 5.1.11 每个订单的总量 5.1.12 历史客户信息 5.1.13 实例的生命周期 5.1.14 订单类型 5.1.15 订单的介绍人 5.2 连贯接口 5.3 小结 第6章 准备基础架构 6.1 将POCO作为工作方式 6.1.1 实体和值对象的PI 6.1.2 是否使用PI 6.1.3 运行时与编译时PI 6.1.4 PI实体/值对象的代价 6.1.5 将PI用于存储库 6.1.6 单组存储库的代价 6.2 对保存场景的处理 6.3 建立伪版本机制 6.3.1 伪版本机制的更多特性 6.3.2 伪版本的实现 6.3.3 影响单元测试 6.4 数据库测试 6.4.1 在每次测试之前重置数据库 6.4.2 在测试运行期间保持数据库的状态 6.4.3 测试之前重置测试所使用的数据 6.4.4 不要忘记不断演变的模式 6.4.5 分离单元测试和数据库调用测试 6.5 查询 6.5.1 单组查询对象 6.5.2 单组查询对象的代价 6.5.3 将查询定位到哪里 6.5.4 再次将聚合作为工具 6.5.5 将规格用于查询 6.5.6 其他查询选择 6.6 小结 第7章 应用规则 7.1 规则的分类 7.2 规则的原则及用法 7.2.1 双向规则检查：可选的（可能的）主动检查，必需的（和自动的）被动检查 7.2.2 所有状态（即使是错误状态）都应该是可保存的 7.2.3 规则应该高效使用 7.2.4 规则应该是可配置的，以便添加自定义规则 7.2.5 规则应与状态放在一起 7.2.6 规则应该具有很高的可测试性 7.2.7 系统应阻止我们进入错的状态 7.3 开始创建API 7.3.1 上下文，上下文，还是上下文 7.3.2 数据库约束 7.3.3 将规则绑定到与领域有关的转换，还是绑定到与基础架构有关的转换 7.3.4 精化原则：所有状态，即使是错误状态，都应该是可保存的 7.4 与持久化有关的基本的规则API的需求 7.4.1 回到已发现的API问题上 7.4.2 问题是什么 7.4.3 我们允许了不正确的转换 7.4.4 如果忘记检查怎么办 7.5 关注与领域有关的规则 7.5.1 需要合作的规则 7.5.2 使用基于集合的处理方法 7.5.3 基于服务的验证 7.5.4 在不应该转换时尝试转换 7.5.5 业务ID 7.5.6 避免问题 7.5.7 再次将聚合作为工具 7.6 扩展API 7.6.1 查询用于设置UI的规则 7.6.2 使注入规则成为可能 7.7 对实现进行精化 7.7.1 一个初步实现 7.7.2 创建规则类，离开最不成熟的阶段 7.7.3 设置规则列表 7.7.4 使用规则列表 7.7.5 处理子列表 7.7.6 一个API改进 7.7.7 自定义 7.7.8 为使用者提供元数据 7.7.9 是否适合用模式来解决此问题 7.7.10 复杂规则又是什么情况 7.8 绑定到持久化抽象 7.8.1 使验证接口成为可插入的 7.8.2 在保存方面实现被动验证的替代解决方案 7.8.3 重用映射元数据 7.9 使用泛型和匿名方法 7.10 其他人都做了什么 7.11 小结 第三部分 应用PoEAA 第8章 用于持久化的基础架构 8.1 持久化基础架构的需求 8.2 将数据存储到哪里 8.2.1 RAM 8.2.2 文件系统 8.2.3 对象数据库 8.2.4 关系数据库 8.2.5 使用一个还是多个资源管理器 8.2.6 其他因素 8.2.7 选择和前进 8.3 方法 8.3.1 自定义手工编码 8.3.2 自定义代码的代码生成 8.3.3 元数据映射（对象关系（O/R）映射工具） 8.3.4 再次选择 8.4 分类 8.4.1 领域模型风格 8.4.2 映射工具风格 8.4.3 起点 8.4.4 API焦点 8.4.5 查询风格 8.4.6 高级数据库支持 8.4.7 其他功能 8.5 另一个分类：基础架构模式 8.5.1 元数据映射：元数据的类型 8.5.2 标识字段 8.5.3 外键映射 8.5.4 嵌入值 8.5.5 继承解决方案 8.5.6 标识映射 8.5.7 操作单元 8.5.8 延迟加载/立即加载 8.5.9 并发控制 8.6 小结 第9章 应用NHibernate 9.1 为什么使用NHibernate 9.2 NHibernate简介 9.2.1 准备 9.2.2 一些映射元数据 9.2.3 一个小的API示例 9.2.4 事务 9.3 持久化基础架构的需求 9.3.1 高级持久化透明 9.3.2 持久化实体的生命周期所需的特定特性 9.3.3 谨慎处理关系数据库 9.4 分类 9.4.1 领域模型风格 9.4.2 映射工具风格 9.4.3 起点 9.4.4 API焦点 9.4.5 查询语言风格 9.4.6 高级数据库支持 9.4.7 其他功能 9.5 另一种分类：基础架构模式 9.5.1 元数据映射：元数据类型 9.5.2 标识字段 9.5.3 外键映射 9.5.4 嵌入值 9.5.5 继承解决方案 9.5.6 标识映射 9.5.7 操作单元 9.5.8 延迟加载/立即加载 9.5.9 并发性控制 9.5.10 额外功能：验证挂钩 9.6 NHibernate和DDD 9.6.1 程序集概览 9.6.2 ISession和存储库 9.6.3 ISession、存储库和事务 9.6.4 得到了什么结果 9.7 小结 第四部分 下一步骤 第10章 博采其他设计技术 10.1 上下文为王 10.1.1 层和分区 10.1.2 分区的原因 10.1.3 限界上下文 10.1.4 限界上下文与分区有何关联 10.1.5 向上扩展DDD项目 10.1.6 为什么对领域模型——SO分区 10.2 SOA简介 10.2.1 什么是SOA 10.2.2 为什么需要SOA 10.2.3 SOA有什么不同 10.2.4 什么是服务 10.2.5 服务中包括什么 10.2.6 深入分析4条原则 10.2.7 再来看一下什么是服务 10.2.8 OO在SOA中的定位 10.2.9 客户-服务器和SOA 10.2.10 单向异步消息传递 10.2.11 SOA如何提高可伸缩性 10.2.12 SOA服务的设计 10.2.13 服务之间如何交互 10.2.14 SOA和不可用的服务 10.2.15 复杂的消息传递处理 10.2.16 服务的可伸缩性 10.2.17 小结 10.3 控制反转和依赖注入 10.3.1 任何对象都不是孤岛 10.3.2 工厂、注册类和服务定位器 10.3.3 构造方法依赖注入 10.3.4 setter依赖注入 10.3.5 控制反转 10.3.6 使用了Spring.NET框架的依赖注入 10.3.7 利用PicoContainer.NET进行自动装配 10.3.8 嵌套容器 10.3.9 服务定位器与依赖注入的比较 10.3.10 小结 10.4 面向方面编程 10.4.1 热门话题有哪些 10.4.2 AOP术语定义 10.4.3 .NET中的AOP 10.4.4 小结 10.5 小结 第11章 关注UI 11.1 提前结语 11.2 模型-视图-控制器模式 11.2.1 示例：Joe的Shoe Shop程序 11.2.2 通过适配器简化视图界面 11.2.3 将控制器从视图解耦 11.2.4 将视图和控制器结合起来 11.2.5 是否值得使用MVC 11.3 测试驱动的Web窗体 11.3.1 背景 11.3.2 一个示例 11.3.3 领域模型 11.3.4 GUI的TDD 11.3.5 Web窗体实现 11.3.6 小结 11.3.7 用NMock创建模拟 11.4 映射和包装 11.4.1 映射和包装 11.4.2 用表示模型来包装领域模型 11.4.3 将表示模型映射到领域模型 11.4.4 管理关系 11.4.5 状态问题 11.4.6 最后的想法 11.5 小结 11.6 结束语 第五部分 附录 附录A 其他领域模型风格 附录B 已讨论的模式的目录
游戏感：虚拟感觉的游戏设计师指南——第一章 定义游戏感
这是一本游戏设计方面的好书 转自天：天之虹的博客：http://blog.sina.com.cn/jackiechueng 感谢天之虹的无私奉献 Word版可到本人的资源中下载   第一章定义游戏感     游戏感是没有一个标准的定义的。玩家和游戏设计师之间都有着一些初始的共同语言，但我们从来没有为了讨论特定游戏而一起去定义游戏感。我们会用“飘”、“响应灵敏”或者“操作很差”来描述一个
一起学技术——java类和对象
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档 文章目录前言一、类和对象1.类和对象2.对类的定义3.对于一些知识的了解二、static关键字1.修饰属性2.修饰属性小结代码（需要仔细思考）final关键字总结 前言 提示：这里可以添加本文要记录的大概内容： 例如：随着人工智能的不断发展，机器学习这门技术也越来越重要，很多人都开启了学习机器学习，本文就介绍了机器学习的基础内容。 提示：以下是本篇文章正文内容，下面案例可供参考 一、类和对象 1.类和对象 在java中一切皆对象，是面.
设计模式——设计模式选择——行为型
对象行为型模式 Chain Of Responsibility——职责链模式 意图 动机 适用性 结构 参与者 协作 效果 降低耦合度该 增强了给对象指派职责的灵活性 不保证被接受 实现 实现后继者链 连接后继者 表示请求 需要考虑增加内容 相关模式 Command（Action、Transaction）——命令模式 意图 动机 适用性 结构 参与者 协作 效果 实现 一个命令对象...
Java学习苦旅（七）——我有对象啦！！！
文章目录引言：对象？什么对象？初识类和对象面向过程和面向对象面向对象的概念面向对象的设计类和对象的关系类和类的实例化类类的基本语法代码示例类的实例化类的成员字段/属性/成员变量成员方法static关键字修饰变量修饰方法封装什么是封装private实现封装多个封装的成员变量需要调用构造方法语法规则注意事项代码示例this关键字代码块本地代码块构造代码块静态代码块匿名对象 引言：对象？什么对象？ 想必大家已经知道，我也有对象了。但我这个对象，和一般人认为的对象或许有点差异。 一般人认为的对象： 我眼中的对
Java SE

62,614

社区成员

307,326

社区内容

发帖
与我相关
我的任务
社区描述
Java 2 Standard Edition
社区管理员
  • Java SE
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章