This discussion is archived
1 2 3 Previous Next 43 Replies Latest reply: Mar 15, 2010 4:40 PM by 843798 RSS

Academic Question about Classes Method and Constructor

843798 Newbie
Currently Being Moderated
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?
  • 1. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    Whats your criterion for inheritance? commonality of code?
  • 2. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    Commonality of code, purpose, and usage. Essentially they're both class members that are invoked and always return a value (since we're dealing with reflection) on successful completion even if the value is null. Invoking either one requires a set of arguments to match the parameter signature. Both have a way with dealing with the need for an instance object from which to be invoked when such an object is required. The methods in getConstructor() and getMethod() in Class could be deprecated in lieu of a single method, getInvokable() (for lack of a better name). It would have the same parameter signature as getMethod(), but it would allow a null value for the String parameter which would indicate for a Constructor object to be returned. (The same would apply for getDeclaredMethod() and getDeclaredConstructor().) There's enough similarity between Method.invoke() and Constructor.newInstance() that they could be called by a single method specified by a common super class. The two classes even the same super class hierarchy and implement the same interfaces.

    It just seems that with the similarities, it's likely that this idea has already been conceived by the designers. So I'm led to conclude that there's probably a specific and pertinent reason why there's not a common super class for the two. My question is simply "What is that reason?"

    Or have I just come to the wrong conclusion, and there is no specific reason?

    Edited by: sledged on Mar 4, 2010 5:07 PM

    Wording.
  • 3. Re: Academic Question about Classes Method and Constructor
    DrClap Expert
    Currently Being Moderated
    Let's take commonality of purpose. Sometimes I want to get constructors, sometimes I want to get methods. There are very few times I want to get "invokables".

    Likewise with commonality of usage. When I have a constructor, I want to use it to construct an object. When I have a method, I want to execute it (and perhaps get its return value if there is one). I don't see those as being the same process although at a high enough level of abstraction they might be.

    So in my opinion abstracting those two fairly different objects into a single concept is just obfuscation and doesn't provide me with any benefit.
  • 4. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    DrClap wrote:
    Let's take commonality of purpose. Sometimes I want to get constructors, sometimes I want to get methods. There are very few times I want to get "invokables".
    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. Sometimes it's not even clear before runtime whether a constructor's needed or a method.
    Likewise with commonality of usage. When I have a constructor, I want to use it to construct an object. When I have a method, I want to execute it (and perhaps get its return value if there is one). I don't see those as being the same process although at a high enough level of abstraction they might be.
    And then you have factory methods, which many times perform the same service as constructors, but are used when you want an instance of a object but the constructor is not accessible, or is better than using the constructor for performance reasons, or does some convenient processing on the object, or don't care if it's a new instance or shared one, etc... As far as usage, factory methods blur the distinction between the constructors and methods.

    An excellent example is how Spring instantiates a bean by either constructor
    <bean id="exampleBean" class="examples.ExampleBean"/>
    or factory method
    <bean id="exampleBean" class="examples.ExampleBean2" factory-method="createInstance"/>
    Spring doesn't care whether you use a constructor or a method, it just needs an "invokable."

    I wonder how different the underlying code for Spring would be if the Constructor and Method classes had a common "Invokable" super class. Just by the above snippets alone we know there's two separate paths in the code: one to call one of the Class.getXMethodX()s and Method.invoke(), and one to call Class.getXConstructorX()s and Constructor.newInstance().
    So in my opinion abstracting those two fairly different objects into a single concept is just obfuscation and doesn't provide me with any benefit.
    Could be that the designers saw it that way, too, which gives a possible answer to my question.
  • 5. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    sledged wrote:
    DrClap wrote:
    Let's take commonality of purpose. Sometimes I want to get constructors, sometimes I want to get methods. There are very few times I want to get "invokables".
    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. If I have adaptors then they do something. They fill a need that the loading framework defines. The fact that the implementation may vary doesn't alter that they can only do what the framework intends. I can't load a JFrame in as a JDBC driver.
    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. 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.)
    Likewise with commonality of usage. When I have a constructor, I want to use it to construct an object. When I have a method, I want to execute it (and perhaps get its return value if there is one). I don't see those as being the same process although at a high enough level of abstraction they might be.
    And then you have factory methods, which many times perform the same service as constructors, but are used when you want an instance of a object but the constructor is not accessible, or is better than using the constructor for performance reasons, or does some convenient processing on the object, or don't care if it's a new instance or shared one, etc... As far as usage, factory methods blur the distinction between the constructors and methods.
    A factory is not a constructor. 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.
    An excellent example is how Spring instantiates a bean by either constructor
    <bean id="exampleBean" class="examples.ExampleBean"/>
    or factory method
    <bean id="exampleBean" class="examples.ExampleBean2" factory-method="createInstance"/>
    Spring doesn't care whether you use a constructor or a method, it just needs an "invokable."

    I wonder how different the underlying code for Spring would be if the Constructor and Method classes had a common "Invokable" super class. Just by the above snippets alone we know there's two separate paths in the code: one to call one of the Class.getXMethodX()s and Method.invoke(), and one to call Class.getXConstructorX()s and Constructor.newInstance().
    It supports two different idioms for constructions. Idioms that existed before Java by the way. They are not equivalent. They are not interchangable.
    So in my opinion abstracting those two fairly different objects into a single concept is just obfuscation and doesn't provide me with any benefit.
    Could be that the designers saw it that way, too, which gives a possible answer to my question.
    Because construction is substantially different than calling a method. In all OO languages.
  • 6. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    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; specifically the method [PropertyUtils.setProperty()|http://commons.apache.org/beanutils/v1.8.2/apidocs/org/apache/commons/beanutils/PropertyUtils.html#setProperty%28java.lang.Object,%20java.lang.String,%20java.lang.Object%29]. This is a good example of knowing that a method is needed, but not know which method until runtime. PropertyUtils.setProperty() needs to know the property name in order to know which method it should invoke, and it doesn't get that information until it is invoked at runtime. Scenarios like this are the most common I've encountered where reflection was needed for method and constructor invocation.
    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.
    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.
    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.
    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.
    An excellent example is how Spring instantiates a bean by either constructor
    <bean id="exampleBean" class="examples.ExampleBean"/>
    or factory method
    <bean id="exampleBean" class="examples.ExampleBean2" factory-method="createInstance"/>
    Spring doesn't care whether you use a constructor or a method, it just needs an "invokable."

    I wonder how different the underlying code for Spring would be if the Constructor and Method classes had a common "Invokable" super class. Just by the above snippets alone we know there's two separate paths in the code: one to call one of the Class.getXMethodX()s and Method.invoke(), and one to call Class.getXConstructorX()s and Constructor.newInstance().
    It supports two different idioms for constructions. Idioms that existed before Java by the way. They are not equivalent.
    Not equivalent, but they do have a fair number of similarities.
    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...)
    So in my opinion abstracting those two fairly different objects into a single concept is just obfuscation and doesn't provide me with any benefit.
    Could be that the designers saw it that way, too, which gives a possible answer to my question.
    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.
  • 7. Re: Academic Question about Classes Method and Constructor
    791266 Explorer
    Currently Being Moderated
    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.
    I can of course not speak for him, but I think he meant that he always knows if he is looking for a method or a constructor. That is at least the case for me. I have used reflections a lot, and I always know if I'm looking for a method or a constructor.

    Kaj
  • 8. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    I can of course not speak for him, but I think he meant that he always knows if he is looking for a method or a constructor. That is at least the case for me. I have used reflections a lot, and I always know if I'm looking for a method or a constructor.

    Kaj
    I thought that may be the case, but I thought it better to clarify my statement than to assume what he meant by his.

    Anyway, my point is that I commonly use reflection because I don't know until runtime which method to invoke, even if I already know well ahead of time it's a method that is needed, and the same with constructors. Additionally, I have run into the occasion that I didn't even know whether I needed a method or a constructor. I'm not saying that everyone who works with reflection runs into this, but I have. I'm more than willing to acknowledge that I may be in a very small minority, but I know I'm not the only one who's encountered this.
  • 9. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    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.
  • 10. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    sledged wrote:
    Anyway, my point is that I commonly use reflection because I don't know until runtime which method to invoke, even if I already know well ahead of time it's a method that is needed, and the same with constructors.
    I can only suppose you are talking about the name of the method. Which has nothing to do with what I am talking about. I am referring to what a given method does.
    Additionally, I have run into the occasion that I didn't even know whether I needed a method or a constructor.
    I can't see how that would not reflect a failure in design or architecture.
  • 11. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    [Spring] 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.
    Given how similar the scenario is to my own experience with reflection, I find it very apt. The only real difference was that instantiation details were passed into my code as method arguments instead of being read from a file.
    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.
    I understand they are two different idioms, and that they're supported to solve different problems. However, supporting both of them (or at least the way that Spring supported them both) still means that Spring only knows whether to invoke a method or constructor at runtime, not before.
    jschell wrote:
    sledged wrote:
    Anyway, my point is that I commonly use reflection because I don't know until runtime which method to invoke, even if I already know well ahead of time it's a method that is needed, and the same with constructors.
    I can only suppose you are talking about the name of the method.
    Any pertinent detail necessary for invocation; Either the method name, parameter types, or class. The BeanUtils scenario I gave was an example of having to wait until runtime to get all three.
    Which has nothing to do with what I am talking about. I am referring to what a given method does.
    I'm talking about using reflection to invoke constructors and methods, including (but not limited to) why reflection would be used towards that purpose, and the similarities between reflectively invoking constructors and methods.
    Additionally, I have run into the occasion that I didn't even know whether I needed a method or a constructor.
    I can't see how that would not reflect a failure in design or architecture.
    I'm not saying whether it would or wouldn't. I can only tell you that in my case it didn't. And I wouldn't consider Spring to suffer from a failure in design or architecture either.
  • 12. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    sledged wrote:
    [Spring] 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.
    Given how similar the scenario is to my own experience with reflection, I find it very apt. The only real difference was that instantiation details were passed into my code as method arguments instead of being read from a file.
    You are suggesting that because Spring allows for both idioms that it somehow applicable to whatever your point is. But all that demonstrates is that Spring supports both idioms. Nothing more. Nothing less.
    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.
    I understand they are two different idioms, and that they're supported to solve different problems. However, supporting both of them (or at least the way that Spring supported them both) still means that Spring only knows whether to invoke a method or constructor at runtime, not before.
    Obviously.
    jschell wrote:
    sledged wrote:
    Anyway, my point is that I commonly use reflection because I don't know until runtime which method to invoke, even if I already know well ahead of time it's a method that is needed, and the same with constructors.
    I can only suppose you are talking about the name of the method.
    Any pertinent detail necessary for invocation; Either the method name, parameter types, or class. The BeanUtils scenario I gave was an example of having to wait until runtime to get all three.
    Not my point. My analogies still stand. The fact that I can pass in all of the names of methods, all arguments, all class names will still not allow me to use a JFrame for a JDBC driver.
    Which has nothing to do with what I am talking about. I am referring to what a given method does.
    I'm talking about using reflection to invoke constructors and methods, including (but not limited to) why reflection would be used towards that purpose, and the similarities between reflectively invoking constructors and methods.
    I agree construction and methods exists. There are still classified as functionally different. And as I pointed out previously they are functionally different in C++, C# and smalltalk as well.

    Can you provide an example of an OO language where that is not the case?

    Additionally, I have run into the occasion that I didn't even know whether I needed a method or a constructor.
    I can't see how that would not reflect a failure in design or architecture.
    I'm not saying whether it would or wouldn't. I can only tell you that in my case it didn't. And I wouldn't consider Spring to suffer from a failure in design or architecture either.
    I wouldn't say Spring has that problem either. But I am certain that Spring is in fact differentiating the two cases. Thus Spring does in fact know and plan for that difference.

    You are the other hand are claiming that you do not.
  • 13. Re: Academic Question about Classes Method and Constructor
    843798 Newbie
    Currently Being Moderated
    Additionally, I have run into the occasion that I didn't even know whether I needed a method or a constructor.
    I can't see how that would not reflect a failure in design or architecture.
    I'm not saying whether it would or wouldn't. I can only tell you that in my case it didn't. And I wouldn't consider Spring to suffer from a failure in design or architecture either.
    I wouldn't say Spring has that problem either. But I am certain that Spring is in fact differentiating the two cases. Thus Spring does in fact know and plan for that difference.

    You are the other hand are claiming that you do not.
    Then you misunderstand the following statement I made earlier:
    sledged wrote:
    Sometimes it's not even clear before runtime whether a constructor's needed or a method.
    To clarify, I was making reference to a closed set of options. Either a method or a constructor and no other possibilities. Like Spring, I knew I was going to invoke one of those two. Also, like Spring I did not know which of the two were going to be invoked until runtime (much less which method or which constructor).
  • 14. Re: Academic Question about Classes Method and Constructor
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    sledged wrote:
    Sometimes it's not even clear before runtime whether a constructor's needed or a method.
    To clarify, I was making reference to a closed set of options. Either a method or a constructor and no other possibilities.
    That still is unclear. Spring doesn't allow absolutely any method. All it allows and expects at that point is a factory.
    Two construction idioms supported. That is different than "constructor" and "method".
    Like Spring, I knew I was going to invoke one of those two. Also, like Spring I did not know which of the two were going to be invoked until runtime (much less which method or which constructor).
    Yet Spring solves the problem by using exactly those two idioms and gets on with solving other problems.
    Spring uses the two idioms because both exist and both solve different problems. It doesn't use them because it must but rather because it can.
1 2 3 Previous Next