aspose file tools*
The moose likes Servlets and the fly likes feedback on using reflection api Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "feedback on using reflection api" Watch "feedback on using reflection api" New topic
Author

feedback on using reflection api

J. Kevin Robbins
Bartender

Joined: Dec 16, 2010
Posts: 969
    
  13

I have a servlet that needs to instantiate DAOs for fetch operations, but the DAO will not be known until runtime. A little reading led me to the Class class and the Reflection api. The following is the code that I came up with, and it works fine, but I'm wondering if this is really the best option. Lines 34 to 40 are the code in question; the rest is just there for explanation of what I'm doing.

It seems like a complex solution to what should be a relatively simple problem. If there is another way to accomplish the same result I'd like to learn about it.


"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61241
    
  66

Two observations:

  • You've got one servlet doing three different things depending upon a parameter that's been passed. Poor form. I'd separate this into three distinct servlets and get rid of the if-else-if-then.


  • You can use reflection to instantiate the object, but then I'd use an interface to call the methods rather than reflection.


  • [Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
    J. Kevin Robbins
    Bartender

    Joined: Dec 16, 2010
    Posts: 969
        
      13

    Bear Bibeault wrote:Two observations:

  • You've got one servlet doing three different things depending upon a parameter that's been passed. Poor form. I'd separate this into three distinct servlets and get rid of the if-else-if-then.


  • You can use reflection to instantiate the object, but then I'd use an interface to call the methods rather than reflection.


  • Thanks for the feedback, Bear, it's always insightful.

    To your first point, this is something I continue to wrestle with; how much is too much for a servlet to do? Does it really make sense to have a dedicated servlet that does nothing but populate the initial page? Related to that is, how much should the servlet do before we pass that functionality off to a separate class at the model layer?

    Now that I think about it a little, I think I understand. An "initialization" servlet would simply populate the page and then be destroyed, and that would lower the memory footprint of the other servlets. Am I thinking along the correct lines here? More, smaller servlets are better than one large servlet, at least from the perspective of the JVM?

    To your second point, guilty as charged. I need to make a habit of writing interfaces and/or abstract base classes instead of just jumping into writing the class I need for the app I'm working on. That's becoming a bad habit and I need to spend more time thinking in those terms and doing some design work before I jump into hacking out code.

    But overall, it sounds like Reflection was the correct solution to this problem, even though it was somewhat poorly implemented?
    William Brogden
    Author and all-around good cowpoke
    Rancher

    Joined: Mar 22, 2000
    Posts: 12789
        
        5
    When I see a line of if-else-then with lots of code all mixed in I think in terms of separate methods for each condition, so much easier to see the control flow and document.

    Back in my Forth days, any routine larger than a (24 line) screen was considered too long.

    Bill
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 61241
        
      66

    Jk Robbins wrote:
    To your first point, this is something I continue to wrestle with; how much is too much for a servlet to do?

    In this case, it's less about how much, but what. Your servlet is doing 3 separate things. Why? Each servlet should do one thing.

    Does it really make sense to have a dedicated servlet that does nothing but populate the initial page?

    Why not?

    Resist the urge to say "it's only doing such, so I'll just shove something else in there too."

    Related to that is, how much should the servlet do before we pass that functionality off to a separate class at the model layer?

    That's a completely different question and a good one. As soon as any kind of business processing or decisions are to be made, the servlet's job is done and any business logic should be in the model.

    Now that I think about it a little, I think I understand. An "initialization" servlet would simply populate the page and then be destroyed, and that would lower the memory footprint of the other servlets. Am I thinking along the correct lines here?

    No. Once a servlet is loaded, it stays around until the app is unloaded. But that's a moot point. Saving memory at the expense of clarity is a losing tactic. Unless you have a demonstrable memory problem, never prematurely optimize because you think something might be more efficient. Prove there's a problem first.

    And if a memory problem does raise its head, I can assure you that the servlet footprint is unlikely to be the culprit.

    More, smaller servlets are better than one large servlet, at least from the perspective of the JVM?

    Immaterial. More, smaller servlets are better for code clarity. Code clarity is job #1 (there are exceptions, but this isn't one of them.)

    To your second point, guilty as charged. I need to make a habit of writing interfaces

    Interfaces are one of the most powerful tools in Java that a lot of people fail to use to their advantage.

    But overall, it sounds like Reflection was the correct solution to this problem

    Reflection is a good way to instantiate a class that's unknown until run-time, but if you already know what the methods are going to be -- and it's clear from your code that you do -- an interface is far superior to invoking methods via reflection. Remember, code clarity!
    J. Kevin Robbins
    Bartender

    Joined: Dec 16, 2010
    Posts: 969
        
      13

    Gottcha. Thanks for the lesson. I've already created another servlet for the results processing. I'll do another for the initialization and add a DAO interface to my todo list.

    William, 24 lines may be a bit too cryptic, but I get the point. I do recall one book that advised if you create a class that's more than two pages long you should rethink it and break it up into two or more classes.
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 61241
        
      66

    I'm not a big fan of the "line count" metrics. If it makes sense to have a big class, then it makes sense. But, if a class, or method, is getting long, it is a sign that you should sit back and think about it. But I'd never break up a single class into multiple classes just because it was getting big, unless it made sense to do so.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: feedback on using reflection api