在设计应用程序时,是否存在太多物体?如何确定何时超出对象模型中的粒度线?
答案 0 :(得分:6)
当你想知道“为什么这是一个对象?”
我最近有一个“BetForgetter”类,我在另一个类中重构为2行代码。
答案 1 :(得分:5)
我假设你在谈论类型而不是对象(我知道它被称为对象模型,但它确实是所涉及类型的模型)。
无论如何,如果您订阅单一责任原则,该原则声明每种类型应该只处理一项责任,那么类型的数量将随着应用程序的增长而增长。
但是,由于尺寸有限,每种类型都应该相当容易理解,假设你有某种结构,你很少(如果有的话)需要一次查看所有类型。 / p>
管理大型软件项目就是将事物分解为可管理的部分并以合理的方式标记它们。如果你这样做,根据我的经验,类型的数量变得不那么重要了。
答案 2 :(得分:3)
可能是另一个问题的症状。
恕我直言 - 只要您拥有良好的项目,命名空间和/或目录组织,以及合理的命名约定,您就应该能够轻松处理任意数量的类。
PS-我假设你在说'对象'时意味着'类'。
答案 3 :(得分:2)
我不确定整个项目范围内的答案是什么,但我通常可以说,如果他们相互依赖太多,那么两个类可能会更好。
答案 4 :(得分:2)
没有严格的规则,但很大程度上取决于程序员的自由裁量权 但作为一般的经验法则,如果你浪费时间写课程到最小的操作,那那就多了......而且很复杂。 如果你写的代码很少,那就太少了。
答案 5 :(得分:1)
不仅太多的对象而且太多的复杂性,我在一天休息后读到我的代码时感到迷失了。
答案 6 :(得分:0)
我会说你应该更担心对象/类太少了。 SRP是值得遵守的,因为它通常会使代码更清晰,更易读。
答案 7 :(得分:0)
我认为在不知道问题的情况下回答你的问题是不可能的。
这很大程度上取决于您尝试使用应用程序解决的问题。
Iraimbilanja 是绝对正确的。如果你开始为所有跨越你的方式创建对象,你很快就会想知道你可以给它们的用途是什么,以及为什么你花时间去创造它们。
答案 8 :(得分:0)
你永远不会有太多这样的人,请问任何体面的Java程序员。
答案 9 :(得分:0)
具有适当OO设计且具有数百个对象的项目处于比具有较少整体类的项目更好的状态。
答案 10 :(得分:0)
一根绳子有多长? (从中间到结尾的长度的两倍,但那是在点旁边)
我认为这取决于你写的是什么以及你是如何写的。对象的数量是很糟糕的,您应该担心对象模型的复杂性而不是您拥有的对象数量。你的对象有多紧密耦合是你需要问的。
如果你有100种不同类型的Bird对象,它们都实现了一个接口而共享方法是在一个抽象类中,那么你没有太多的对象,因为你可能需要每个Bird采取不同的行为。
然而,如果你有一堆所有实现相同代码的obeject,那么你有太多的对象,并且可以重构为少。
同样,如果你有一个包含许多不同功能的庞大类,那么你的类太少了。
除非你的课程做同样的事情或复制框架中其他课程已经做过的事情,否则你没事。
请记住,因为你可以使用遗产并不意味着你必须,组成往往更好。