The Inversion-of-Control
(IoC) pattern, is about providing any kind of callback
(which controls reaction), instead of acting ourself directly (in other words, inversion and/or redirecting control to external handler/controller). The Dependency-Injection
(DI) pattern is a more specific version of IoC pattern, and is all about removing dependencies from your code.
Every DI
implementation can be considered IoC
, but one should not call it IoC
, because implementing Dependency-Injection is harder than callback (Don't lower your product's worth by using general term "IoC" instead).
For DI example, say your application has a text-editor component, and you want to provide spell checking. Your standard code would look something like this:
public class TextEditor {
private SpellChecker checker;
public TextEditor() {
this.checker = new SpellChecker();
}
}
What we've done here creates a dependency between the TextEditor
and the SpellChecker
.
In an IoC scenario we would instead do something like this:
public class TextEditor {
private IocSpellChecker checker;
public TextEditor(IocSpellChecker checker) {
this.checker = checker;
}
}
In the first code example we are instantiating SpellChecker
(this.checker = new SpellChecker();
), which means the TextEditor
class directly depends on the SpellChecker
class.
In the second code example we are creating an abstraction by having the SpellChecker
dependency class in TextEditor
's constructor signature (not initializing dependency in class). This allows us to call the dependency then pass it to the TextEditor class like so:
SpellChecker sc = new SpellChecker(); // dependency
TextEditor textEditor = new TextEditor(sc);
Now the client creating the TextEditor
class has control over which SpellChecker
implementation to use because we're injecting the dependency into the TextEditor
signature.
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
static
members belong to the class instead of a specific instance.It means that only one instance of a
static
field exists[1] even if you create a million instances of the class or you don't create any. It will be shared by all instances.Since
static
methods also do not belong to a specific instance, they can't refer to instance members. In the example given,main
does not know which instance of theHello
class (and therefore which instance of theClock
class) it should refer to.static
members can only refer tostatic
members. Instance members can, of course accessstatic
members.Side note: Of course,
static
members can access instance members through an object reference.Example:
[1]: Depending on the runtime characteristics, it can be one per ClassLoader or AppDomain or thread, but that is beside the point.