Separation of objects into the most fundamental parts

Question

Not sure if the headline reflects what I'm trying to say here.

When designing in OO, I have to break objects into my most specific areas, so if I have a factory object that creates objects, but later I come across a way to create objects for another purpose, although they may be the same objects, is it worth it create a separate fragment or just add to exsiting.

My biggest concern is to take lessons with a bunch of things or break up objects and dilute my projects in a sea of ​​classes.

Any help?

EDIT:

I assume that part of the note / subheading part of me wants to know the level of detail that you should use in the program. Kind of how low should you go?

Answer 1

My biggest concern is to combine classes with a bunch of things or sharing objects and diluting my projects into a sea of ​​classes

This is a very relevant point and in any even reasonably reasonable size, an extremely difficult task, primarily because it is realistic, the requirements in most cases develop over time. This is where Refactoring comes in. You develop based on what you know at any moment, and try not to jump too much faith in what you think the system MAY evolve.

Given that you know what you are building right now, you are developing your classes, trying to make the most of OO concepts - for example, encapsulation / polymorphism. This in itself, as others have noted, can be, as is well known, difficult to access, and in this case experience, both in the design of OO systems and in the field of knowledge, can really be useful.

Design based on what you know → Build It → Overview → Refactoring it → Re-design → and it goes on and on ..

Answer 2

Finding the right level of detail and responsibility is what makes OOP design so complex. We can help you with a specific case, but not with anything in common. If there were algorithms or rigorous methodologies for how to solve them, everyone could be an OOP developer.

Answer 3

The rule of thumb that I like when deciding: "Is it getting too big now?" "Can I explain the purpose of this briefly?" If you start typing caveats and a lot of affectionate words to explain the functions of a component of your design (be it a class, a member variable, a method, or something else), this can be a good indicator that it is becoming too complex and needs to be separated.

Answer 4

In your particular case, if you already have a factory object, then the DRY principle (Do not Repeat Yourself) would say that it is a bad idea to create another factory that does the same.

Is this the real problem you are facing? Or just fear about how your code can grow in the future?

Answer 5

If you use the same type of object to solve very different problems, you may need to redesign the class to focus on separation of problems. If you need a more specific answer, you need to specify an example of the type of class that will need this function.

---

I could have formulated Q incorrectly. I think I would not repeat it myself, this is just a case where to put the code, it can be added to the exsiting factory, which creates design objects for exhibiting data for Excel. On the other hand, I could see that it could also have its own factory for importing Excel data. Both plants produce the same facilities, but the work is completely different. -

If you do not or do not plan to perform any abstraction of the class (subclassing or using interfaces), you may not need to use the factory template. A factory pattern is usually best suited for delivering base class objects or for implementing a specific interface.

Answer 6

And factories will produce the same facilities, but the inner workings are completely different.

Not sure if I understood you correctly, but it looks like a candidate for the AbstractFactory template.