I've studied design pattern and oop principles, still feel that there is something missing in most design theories. Maybe the fact is that there is not a 'theory' as it is in database design.
Let me explain with an example.
Suppose that i want to model different ways to produce orange juice.
Let say that i start by a class
Oranges, that models a lot of oranges that will be of a certain variety, of a certain ripeness, they may have been froozen etc., ant these will by my Oranges class properties.
Then i continue by providing Orange with a squeeze method.
This seems to be correct, because ties togheter the method to the data it applies to, that is the precondition to achieve encapsulation and other valuable oop principles.
But quickly it comes out that it has not been a good choiche because there is not just one way to squeeze an orange. It would be preferrable to have a
Juicer class whose instances contains details of the juicing method: by hand, with an electric juicer, including the pulp, not to mention mixing different varieties of oranges. Where the latter opens an whole new cathegory of possibilities that were not available (or not achievable with ease) if each Oranges instance would have been processed using its squeeze method.
Say that we have performed a 'refactoring' of our oo architecture and move to another similar example that will get us to the point.
It is now a common practise to use an ORM to save class instances to database and get them back later. In what is it similar to the Oranges class example? Well, here i have a class whose instances may be persisted to a database, that is 'allow a particular process'. But the class itself does not contain the logic for doing so, that actually is in the ORM classes. So it seems that the same process of 'externalization' of the Oranges example has taken place in this case too.
And here is the question
Given that it is desireable to reduce the number of attempts-and-refactorings to the minimum, what are the questions that a programmer should put in order to determine precociously if a method should be externalized to another class? Are all the methods of a class exernalizable or is there a set of core methods that are inherently of the class itself and so not externalizable?
As i said in the beginning, i'm not completely clueless, i feel more like that a 'comprehensive' theory is missing.
It's easy to put some examples:
if i have a class whose instances represent invoices, i will have a method 'calculateTotalAmount'. This is clearly an inthrinsic, core method of that class, as oppsed to the methods for saving that invoice to the database that will be 'external' of the class itself. But this is not a 'final answer', but a starting point that serves to demonstrate that 'not all methods are equal', but methods may be divided into cathegories. How many (useful) cathegories can we make, and are there methodologies that put these questions?