• Post Reply Bookmark Topic Watch Topic
  • New Topic

alternative to reflection  RSS feed

 
yuvaraj vanarase
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi
can anyone plz give me an example where one tends to use reflection phenomenon when one should not..?
Here reflection could be avoided [as causes overhead] and alternate solution should be used.
what can be that alternate solution and how..?

[In short : how interface can be alternative to reflection..?]

plz reply asap.

Thanks.
yuvaraj
 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Introspection (a.k.a. reflection) is used for runtime discovery of fields and methods and related items. If you can expose that information at compile time you can avoid introspection. Interfaces provide compile time knowledge and you can distribute them across many classes.

You have to go out of your way to use reflection so it's not something that even a mildly experienced programmer would use by mistake. I think if one is using reflection when they should not be they need a remedial study session.
[ February 22, 2006: Message edited by: Rick O'Shay ]
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The choice reflection-versus-interface is not so cut-and-dried. Consider this advice from Spring's reference manual:


Implementing the org.springframework.beans.factory.InitializingBean allows a bean to perform initialization work after all necessary properties on the bean are set by the BeanFactory. The InitializingBean interface specifies exactly one method:

void afterPropertiesSet() throws Exception;

Note: generally, the use of the InitializingBean marker interface can be avoided (and is discouraged since it unnecessarily couples the code to Spring). A bean definition provides support for a generic initialization method to be specified. In the case of the XmlBeanFactory, this is done via the init-method attribute. For example, the following definition:

<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>



Is exactly the same as:

<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>



but does not couple the code to Spring.
 
yuvaraj vanarase
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
infact, i have read that reflection should not be used if your problem gets solved by using interfaces. However i didnt understand this ...i mean i didnt get any example to convince me this.
Could you please give me any example ..where one can use interfaces and reflection also ..but using interface would b healthy..?

thanks in adv,
yuv
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One argument is that using interfaces is a more strongly-typed solution. With reflection, a mispelling isn't caught until runtime. In my previous example, from Spring, the following two lines are treated equally until it comes time to use them, and then one has a spelling error:

<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>

<bean id="exampleInitBean" class="examples.ExampleBean" init-method="inti"/>

Of course, this is the age-old dynamic-versus-static argument. Folk that like to be dynamic complain that Java needs better built-in support for unit-testing, because in the dynamic work that replaces some of the safety that otherwise gets enforced with compile-time type checking.
 
Zkr Ryz
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Using reflection allows you to get knowledge about the classes loaded into a system in a highly dynamic way, the main benefit about using it would be that you can interact with classes that were not present at compile time. This is the good part. For example if you are building a Java to XML tool, you should necessary use reflection to get to know the classes you want to map ( by the time you build the tool, those classes might not even exists ).
But this power comes at a price:

Quoting Joshua Bloch 1:

You lose all the benefits of all compile-time checking.
The code required to perform reflective access is clumsy and verbose.
Performance suffers.

Reflection is used only at design time. As a rule, objects should not be accessed reflectively in normal applications at run time.

and continues:

Sophisticated applications, like class browsers, object inspectors, code analysis tools, and interpretive embedded systems demand the use of reflection.[...] If you have any doubts as to whether your application falls into one of these categories, it probably doesn't


But what to do if you need to interact with classes that does not exists by the time you create your code? the best way is to provide an interface that the new classes must implement. An example is the JDBC API. All java.sql.Connection, java.sql.PreparedStatement, java.sql.ResultSet and many others are interfaces. The database provider, implements these classes in its driver, thus allowing the programmer to access the database in a consistent way.

1 Joshua Bloch. Effective Java Programming Language Guide.
This is an excellent book.
[ February 24, 2006: Message edited by: Zkr Ryz ]
 
Michael Ernest
High Plains Drifter
Sheriff
Posts: 7292
Netbeans IDE VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rick O'Shay:

You have to go out of your way to use reflection so it's not something that even a mildly experienced programmer would use by mistake. I think if one is using reflection when they should not be they need a remedial study session.

I heartily disagree. I'm very pleased to see cogent posts here to that effect.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!