Academic Question about Classes Method and Constructor

Question

Given the similarity between the Constructor class and the Method class, why don't they have a common super class for the methods they have in common that are unique to them?

Answer 1

sledged wrote:
jschell wrote:
sledged wrote:
I've found that the most common reason for invoking a constructor or method through reflection is because you don't know what you need until runtime, commonly because what you want can vary based on context, or is otherwise being specified external to the bit of code that uses reflection. Not true. The fact that I don't need it until runtime never means I don't know what I need.Never? Then your experiences with the reflection API have been different than mine. Either that or I wasn't very clear. Let's take Apache Commons BeanUtils;
It doesn't matter how you access a class. You can't use it unless
1. You have a goal in mind
2. That object in some way fulfills that goal.
3. You know how that object fulfills that goal.
And as I already pointed out you can't use a JFrame for a JDBC driver. Simple as that. Nor can I create a new class that implements, for example, ProC (Oracle method to embed access into C code) using my own idiom despite that it provide database access. It MUST match what jdbc expects.
Sometimes it's not even clear before runtime whether a constructor's needed or a method.
I disagree. That isn't true in any OO language.Perhaps not out the box, but it can be true when using certain tools built from the OO language. Let me continue using the Spring framework as an example. It does not know whether to use a method or a constructor to instantiate any bean defined in the XML configuration metadata until that XML file is read and it determines whether or not a given bean definition has the "factory-method" attribute. The XML file in not read until runtime, therefore with any given bean defined therein, Spring does not know until runtime whether to use a constructor or method.Not apt at all.
As I already said those are two different idioms. Spring supports them because they are used to solve different problems not because they wish constructors didn't exist.
>
The basis of OO is the "object". You can't have a method without the object in the conceptual OO model. (And in Smalltalk that is always true.)
True, but one may not always care how the "object" is provided. When the method [Properties.load(InputStream)|http://java.sun.com/javase/6/docs/api/java/util/Properties.html#load%28java.io.InputStream%29] is called, it isn't going to care whether the InputStream argument was instantiated by one of the FileInputStream constructors, or if it came from a [URL.openStream()|http://java.sun.com/javase/6/docs/api/java/net/URL.html#openStream%28%29] method call. It'll work with either regardless of their respective origins.
That of course has nothing to do with anything. Unless you are suggesting that construction in any form should not exist.
A factory is not a constructor.I'm not saying it is. I'm just pointing out a number of the similarities between the two.
So? There are many similarities between RMI and JDBC but that doesn't mean that they should be the same.
With your argument you can claim that construction doesn't exist because any method, regardless of intent, that uses 'new' would eliminate the need for construction. And that isn't what happens in OO languages.I wouldn't claim that construction doesn't exist in any OO language. But I do know that in ECMAScript construction exists on the basis of whether or not a method is called with the 'new' operator. So in ECMAScript a single method can also be a constructor.
And in C++ I can entirely circumvent the object construction process. Actually I can do that in JNI as well.
I would still be a bad idea.
>
They are not interchangable.Normally, no, but with a high enough level of abstraction, they can become interchangeable. Again, the Spring framework is a great example. It doesn't care if a method or a constructor is used, and it won't know which one has been chosen until runtime. I don't even think Spring checks the return type of a method, so you could use a void return type method. (Although I don't know what that would buy you because the bean would always be set to null, but still...)
No.
Based on that argument every possible programming problem could be solved by simply stating that one must implement the "doit()" method. One just need to generalize it enough.
Different APIs exist because there are in fact differences not because there are similarities.
Over generalization WILL lead to code that is hard to maintain. Actually generalization itself, even when done correctly, can lead to code that is actually more complex.
Because construction is substantially different than calling a method. In all OO languages.Yes, construction is different, but the actual call to a constructor and a method is only syntactically different with the presence of the 'new' operator. With reflection the difference is between calling Method.invoke() and Constructor.newInstance(), and, as I mentioned earlier, there's enough similarity between the two methods that they could be called by a single method specified by a common super class.Which does not alter the fact that the process of achieving the result is fundamentally different.