Dan*_*Dan 23 language-agnostic oop
我试图理解面向对象.我当然理解它,但有时候我并不是100%清楚.你如何决定什么应该变成一个对象(另一个大整个对象的小对象部分)或者什么不值得成为一个对象,或者它应该只是那个大整个对象的属性？
对于一扇门,我猜门把手应该是一个独立的物体,但是你插入钥匙的中间部分应该是一个独立的物体还是什么？这是一个简单的例子,所以我可以解释我的困惑.您可以使用您的示例,如果它可以帮助您更好地表达您的观点.
我在想,如果我要多次使用它,我应该把它作为一个对象.我认为这是解决这个问题的实用方法,你同意吗？
谢谢
And*_*s_D 30
一如既往,答案是不幸的:这取决于......
一开始,你有某种环境,你想为它创建一个模型.但你不会模仿每一件事,你会专注于重要的事情.这就是我开始的原因:这取决于.这取决于完成任务所需的详细信息.
乘坐汽车和它的轮子 - 如果你为一个城市建模并想要一些交通,你可以创建一个属性为'numberOfWheels'的'Car'类.但是如果你设计汽车,那么你很可能想要创建一个类'Wheel',并将其中的四个添加到'Car'类.
经验法则:
编辑
因为你强调了"多用途"方面:我不认为这是决定是否使用课程的一个方面.想想一个简单的计数器,一个for循环中的整数值.你将使用这个概念数百次,但我敢打赌,你永远不会想到将这个可怜的小伙伴包装int成'计数器'类 - 只是因为你多次使用'计数器的概念'.
Mic*_*man 12
第一:忘记物理对象.我知道所有的教科书"学习示例"都使用它们,但是当你试图模拟一个真实的系统时,你只会迷惑自己.物理对象和对象之间没有直接关系.
Object是一种数据结构,它与一组可以对该数据结构进行操作的方法相结合.对象的属性保持对象状态,方法对状态进行操作.
您尝试建模的系统状态是什么？它是否存在于门,旋钮或两者的某种组合中？
有一些方法试图在编码开始之前明确指定对象模型.其他方法(例如,TDD)允许对象模型通过编码过程出现.在您的情况下,我建议使用TDD编写一些中小型应用程序,以便您可以看到各种模式的优缺点.很少有一种"正确"的方式来模拟给定的情况,但有些模型比其他模型更容易使用和理解; 认识到适用于你面前情况的模式带来了经验.
所以,底线:制作很多模特.考虑应用程序域,对它们进行建模和编码.这样做会使事情变得更加清晰.制作一个沙箱,然后跳进去.
Chr*_*ley 10
在决定某件事物是否是某个物体时,请问自己是否有以下物品......
州
候选人是否有重要的州？如果没有,那么它上面的所有方法都可能只是微弱相关.在这种情况下,您可能已经确定了可重用函数模块库.
行为
对象实际上是否在域中执行某些操作？例如,它只是充满了操纵结构或记录的访问器.
身分
对象是否真的存在于域中作为可识别的实体？该实体是否存在一些天生的方面,使其与其他类似的实体区别开来？门把手就是一个例子 - 由于一个门把手可能与另一个门把手相同,因此它并没有真正的特征.
如果你对其中一些回答"否",那么你可能没有一个对象 - 而且库或模块可以是一个有价值的可重用工件
最重要的是,不要担心......
我也不会过分担心这个问题的重用方面.设计类层次结构就像设计可扩展的软件一样 - 早期优化太容易了.在一张纸上画出一个设计,如果可以的话,用一些手绘的交互图验证设计.您会发现,随着时间的推移,您将真正了解真正有价值和可重复使用的内容.
我建议您考虑一下将如何使用它。想想你必须对你的“东西”进行哪些操作，然后考虑什么是最简单的方法。有时将其设为另一个对象的属性会更容易，有时将其设为自己的新对象会更容易。
没有通用的方法，可能有很多因素可以使一种解决方案变得更好。只需单独考虑每种情况即可。
补充：以门/门把手/钥匙孔为例 - 您将如何处理钥匙孔？以下是一些因素，使得将钥匙孔作为一个单独的对象变得合乎逻辑：
使其成为属性的情况相反：