The name reflection is used to describe code which is able to inspect other code in the same system (or itself).
For example, say you have an object of an unknown type in Java, and you would like to call a 'doSomething' method on it if one exists. Java's static typing system isn't really designed to support this unless the object conforms to a known interface, but using reflection, your code can look at the object and find out if it has a method called 'doSomething' and then call it if you want to.
So, to give you a code example of this in Java (imagine the object in question is foo) :
Method method = foo.getClass().getMethod("doSomething", null);
method.invoke(foo, null);
One very common use case in Java is the usage with annotations. JUnit 4, for example, will use reflection to look through your classes for methods tagged with the @Test annotation, and will then call them when running the unit test.
There are some good reflection examples to get you started at http://docs.oracle.com/javase/tutorial/reflect/index.html
And finally, yes, the concepts are pretty much similar in other statically typed languages which support reflection (like C#). In dynamically typed languages, the use case described above is less necessary (since the compiler will allow any method to be called on any object, failing at runtime if it does not exist), but the second case of looking for methods which are marked or work in a certain way is still common.
Update from a comment:
The ability to inspect the code in the system and see object types is
not reflection, but rather Type Introspection. Reflection is then the
ability to make modifications at runtime by making use of
introspection. The distinction is necessary here as some languages
support introspection, but do not support reflection. One such example
is C++
There are several differences between HashMap
and Hashtable
in Java:
Hashtable
is synchronized, whereas HashMap
is not. This makes HashMap
better for non-threaded applications, as unsynchronized Objects typically perform better than synchronized ones.
Hashtable
does not allow null
keys or values. HashMap
allows one null
key and any number of null
values.
One of HashMap's subclasses is LinkedHashMap
, so in the event that you'd want predictable iteration order (which is insertion order by default), you could easily swap out the HashMap
for a LinkedHashMap
. This wouldn't be as easy if you were using Hashtable
.
Since synchronization is not an issue for you, I'd recommend HashMap
. If synchronization becomes an issue, you may also look at ConcurrentHashMap
.
Best Answer
As indicated by several other answers, EJBs are perfect for implementing the service layer. They are a very modern, lightweight kind of bean in Java EE. Despite the name you cannot compare them with the draconian heavy weight EJB2 beasts that were in J2EE. Everyone agrees those were a disaster, but it's not 2002 anymore.
Ever since EJB3 (2006), EJB beans have been a perfectly fine technology.
They help a lot here by providing declarative transactions (every entry method automatically starts a transaction if one is not already in progress, although this can be changed if desired), pooling, security, locking, remoting and then some. See the following answers for some additional details:
Transactions have been explained here, but to add to this: it's not something that's only needed for highly complex, highly secure systems. I would go as far to state it's a basic requirement even when only dealing with databases. If I process a simple order, I want that the inventory and the order are both updated or both not at all. This is as basic as having PKs and FKs in your database to ensure integrity.
EJBs make it trivial to manage transactions. Without EJBs there's a lot of boilerplate code for starting, committing or rolling-back the tx.
One should also not underestimate the benefits of pooling and stubs that EJB provides. It means a bean can have a lot of EJBs injected, and you don't have to worry about them being instantiated each and every time such a bean is created. This would otherwise especially be troublesome when not all EJBs would be used every time.
Because of pooling however, only very lightweight stubs are injected, which are more akin to a kind of URLs that point to an actual instance. These cost next to nothing in terms of memory or cpu overhead to inject.
EJBs also feature annotations to declare them being Singletons, arrange their locking behavior (write locks/read locks), declaring one should be initiated at startup, allow them to manage a so-called extended persistence context (a persistence context not scoped to a TX), etc.
These are all concerns you don't want in your slim entities. In many architectures, a User object for instance is a simple data entity that I want to send across layers. I don't want my User instance to have a sendMsg() method and have a JMS resource as a dependency, so that message sending can suddenly be done from some client. I'm not really sure why people think this is somehow 'natural' and 'OOP'.
In the real world I also don't invoke a sendMsg operation on my friend Joe whenever I want to send him a postcard. Instead, I address a card and bring it to the postoffice or put it in a postbox.
I also don't invoke a bake() operation on a cake. Instead, I put the cake in an oven, etc.