将对象分割成最基本的部分
不确定标题是否表达了我在这里想说的内容。
在面向对象中设计时，我是否应该将对象分成最具体的区域 - 因此，如果我有一个处理创建对象的工厂对象，但后来我遇到了一种为另一个目的创建对象的方法，即使它们可能是相同的对象是否值得创建一个单独的fcatory或只是添加到现有的。
我最担心的是用大量的东西来增加类，或者分割对象并将我的项目稀释成大量的类。
有什么帮助吗？
编辑：
我想在旁注/子主题中，我想找出您应该在程序中使用的粒度级别。有点，你应该降到多低？
Not sure if the title captures what I'm trying to say here.
When designing in OO should I be splitting my objects up into their most specific areas - so if I have a factory object that deals with creating objects but later on i come across a way of creating objects for another purpose even though they may be the same objects is it worth creating a seperate fcatory or just add to the exsiting.
My biggest worry is bulking up classes with tons of stuff, or splitting objects and diluting my projects into a sea of classes.
Any help?
EDIT:
I guess on a side note/sub topic part of me wants to find out the level of granularity you should use in a program. Kind of, how low should you go?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
观点，即使在任何规模合理的项目中，也很难在前面得到正确的解决方案，特别是因为实际上，在大多数情况下，需求本身会随着时间的推移而发展。
这就是“重构”的用武之地。您根据您在任何给定点所知道的知识进行设计，并且尽量不要对您认为系统可能发展的方向做出太多的信念飞跃。
鉴于您知道您现在正在构建什么，您可以设计您的类，尝试尽可能地利用 OO 概念 - 例如封装/多态性。正如其他人也指出的那样，这本身是非常难以实现的，而这正是设计 OO 系统方面的经验以及该领域的知识真正可以派上用场的地方。
根据您所知道的进行设计 -->构建它 -->回顾一下 -->重构它 -->重新设计-->它一直持续着..
This is a very valid point and in any even reasonably sized project, extremely difficult to get right up front especially because realistically, requirements themselves evolve over time in most cases.
This is where "Refactoring" come in. You design based on what you know at any given point and try not too make too many leaps of faith as to what you think the system MAY evolve to.
Given that you know what you are building right now, you design your classes trying to make the best possible use of OO concepts - eg encapsulation / polymorphism. This is itself, like others have noted as well, can be notoriously difficult to achieve and thats where experience, both in designing OO systems as well as knowledge of the domain can really come in handy.
Design based on what you know --> Build It --> Review it --> Refactor it --> Re-design --> and it goes on and on..
找到正确的细节级别和职责是 OOP 设计如此困难的原因。我们可以帮助您解决特定案例，但无法解决一般性问题。如果有算法或严格的方法论来解决这个问题，那么每个人都可以成为 OOP 设计师。
Finding the correct level of detail and responsibility is what makes OOP design so difficult. We can help you with a specific case but not with anything this general. If there were algorithms or strict methodologies of how to solve this, everyone could be an OOP designer.
我喜欢用一个经验法则来决定“现在是不是太大了？”是“我能简明地解释一下它的目的吗？”如果你开始不得不引入警告和大量狡猾的词语来解释你的设计组件的功能（无论是类、成员变量、方法还是其他什么），这可能是一个很好的迹象，表明它变得太复杂并且应该分开。
A rule of thumb I like for deciding "is this getting too big now?" is "can I explain the purpose of it concisely?" If you start having to introduce caveats and lots of weasel words to explain the functions of a component of your design (be it class, member variable, method or whatever) it might be a good indicator that it's getting too complex and should be split up.
在您的具体情况下，如果您已经有一个工厂对象，那么 DRY 原则（不要重复自己）会说创建另一个做同样事情的工厂是一个坏主意。
这是您面临的实际问题吗？或者只是担心您的代码将来会如何增长？
In your specific case, if you already have a factory object then the DRY Principle (Don't Repeat Yourself) would say that it's a bad idea to create another factory that does the same thing.
Is this an actual problem that you face? Or merely a fear about how your code might grow in the future?
如果您使用相同类型的对象来解决截然不同的问题，那么您可能需要重新设计该类以专注于关注点分离。如果您需要更具体的答案，您将需要提供需要此功能的类类型的示例。
如果您不执行或计划执行任何类抽象（子类化或使用接口），您可能根本不需要使用工厂模式。工厂模式通常最适合提供基类类型的对象或实现特定接口的对象。
If you are using the same type of object to solve drastically different problems then you may need to redesign the class to focus on seperation of concerns. If you need a more specific answer, you will need to provide an example of a type of class that would need this functionality.
If you aren't doing or plan on doing any class abstraction (subclassing or using interfaces) you may not need to use the factory pattern at all. The factory pattern is generally best suited for supplying objects of a base class type or that implement a specific interface.
不确定我是否理解正确，但这听起来像是 AbstractFactory 模式的候选者。
Not sure if I've understood you correctly, but this sounds like a candidate for the AbstractFactory pattern.