What's Wrong with Reflection?

• Reflection useful for: bean builders, object inspectors, object serialization, automated testers
• Use reflection when you don't know what's coming, and you want to do something to objects
• Programming with types is more efficient than reflection, exceptions.
• Can find more errors sooner, because compiler does type checking.
• Encourages meaning-rich code: a type name implies an interface, a set of services, and a semantic contract.
• Types form a vocabulary with which team members talk about the program -- they are the units of communication

Reflection: Method Name in HTML Post

• I think it's a way of gaining flexibility and not losing it, if you design your application to be able to handle any Java object that can be thrown at it :) Always having to know the type of things that are coming at you is a woeful left-over from strong-typing fanatics.
• I've used code such as:
  
  this.getClass().getMethod(methodName, null).invoke(this, null);
  
  in a servlet where 'methodName' is a CGI parameter. I agree that runtime info should be avoided if possible, but I think that in this case it is justified. What does anyone else think?

I.e., don't design an API that takes a method name, design APIs that take type names.

Performance hit from reflection doesn't matter here because the network latency is much bigger. But I would have gone for an interface or class name that has a method in it that has defined semantics.

Use ResourceBundles as an example.

Can talk a bit about weak typing. weak typing may actually make programmers more productive without much cost in runtime robustness (word of mouth stories about Python). Java needs strong tpying because the design center of Java's architecture is network mobility of code and objects. A big part of that is security, and the cornerstone of Java's security model is type safety. Since Java is a strongly typed language, should use it that way (except probably for enums). Of course, the argument against enums (the fake it way that is in Bruce's book) is a combination of the weak typing over strong typing argument (you get a runtime error instead of a compile time error) plus tradition (in most Java APIs enums are just defined constants), of course blindly following tradition is well discussed in the Lottery. The language does guide one in how you design with it.

What you end up with in an API design is no real objects, just blueprints. Like an architect designs a house but in the end there's no real house, just the blueprints. Or a machine designer designs a machine and in the end there's no real machine, just the plan for that machine. In an object-oriented API, those blueprints take the form of types (in Java, classes and interfaces), each of which communicates some semantics to humans that use the types. That's what object-oriented API design is, designing types that marry syntax of how you request services with semantics that describe the full range of possible behavior when you request that service.

My suspicion about weak typing is this. 99.9% of the time the programmer probably does get the semantics guessed right. (Remember monomorphic, bimorphic, and polymorphic empirical percentages?) Plus how often do two identical method signatures with different semantics actually happen in practice? The other thing is that the semantic contract of a method in a type is only fulfilled to the extent that there aren't bugs (could come not just from accidents, but misunderstandings of the semantic contract fence among clients and service providers -- its real challenging to get those understandings compatible) Thus, the small percentage of times when a programmer may guess the semantics wrong in a weakly typed language may be less than the times there's a bug in the provider's implementation of the contract, so the programmers productivity may be more enhanced by the ability to not have to declare variables with known types.