Java Reference
In-Depth Information
assert hasNext : "No result when getting generated keys for " + title;
int textId = rs.getInt(1);
rs.close();
executor.submit(() -> System.out.println(title));
return textId;
}
public static void main(String[] args) throws Exception {
createDatabase();
}
}
This code is accomplishing a relatively simple task, but it's already becoming impossible to follow. This
reveals the problem with imperative code: it has limited semantic structure. A lot is happening, but not a lot
is communicated to the reader about why those things are happening. Instead, the script's gritty details are
entirely exposed in a mostly unstructured stream of instructions.
Despite the obvious drawbacks of imperative programming, there are still a number of places where
it is very useful. Because imperative code is so quickly written, it works well for very short bits of code
with a clear and simple purpose. Unit tests, for instances, are almost universally imperative in Java. Most
method bodies in Java are imperative, as well, which is part of the motivation for keeping them very short.
Other languages and contexts also make the imperative paradigm a more natural fit, such as bash or perl
for system administration scripts. In general, if you can keep the whole thing in your head at the same time
without any confusion, then the imperative style is a nice way to go.
Object-Oriented Programming Paradigm
The imperative programming paradigm lead to many struggles with maintainability, composability, and
reusability. Out of these struggles came a refinement of that paradigm called the object-oriented paradigm.
Practically from its inception, Java was the poster child for object-oriented programming. In imperative
programming, your application is a series of instructions. In object-oriented programming, your application
is still a series of instructions, but the application can be quite clever in deciding which instructions to call.
The application has many containers for a set of instructions - objects - and the programmer specifies at
runtime which container's instruction to call. Within an object-oriented paradigm, an imperative program
can be thought of as a program with one global object, and all the methods are on that single object.
Object-oriented programming is a derivative of imperative, but brings with it many advantages. The
biggest advantages are that you can encapsulate state: no longer does everything need to know everything
about everything. Instead, the developer can capture all that relevant information inside of a single object,
and expose instructions that use that state without exposing that state. The other advantages of object-
oriented programming derive from this encapsulation stunt: for instance, I can specify a contract about
the instructions that you have to implement, and then you can provide any implementation that you like to
satisfy that contract.
Even though Java is an object-oriented programming language at its heart, not all Java code is object
oriented. You will recognize object-oriented Java code by a proliferation of small, extensible types that are
composed together to build up more advanced objects. Methods will be a thin wrapper around the object's
properties, with minimal business logic attached to delegation. In object-oriented programming, every class
is like a lazy manager: it delegates work to its constituents as quickly as possible.
