Re: Lazy initialization
Philipp wrote:
It is probably not a good idea to place getBooks() as an instance
method in the Book class. In order to call it, you will need a Book
object. You would call it like this:
Book myBook = new Book("1234-45");
List<Book> list = myBook.getBooks();
There might be nothing wrong with that, in particular because the Book object
contains state that might be relevant. Among other things, that state might
include information to make the connection and the connection itself. Often
these things are not readily shareable, necessitating that they be instance level.
Creating a dummy Book object to do this, doesn't make much sense.
In this simplified, stripped-down case it doesn't seem to, but in reality it
usually makes a lot of sense.
The simplest modification would be to make that method static ( public
static List<Book> getBooks(){...} ) . As such it becomes something
Bad advice in many cases.
like a helper method which can be called directly using code like
(note, we use the class the name before the dot):
List<Book> list = Book.getBooks();
Making methods (and variables) static introduces risk that is much easier to
manage at instance level.
One determinant is whether there is state that cannot easily be shared.
Another is thread safety. Such considerations may mandate instance-level action.
On the other hand, you are writing about database connection etc. So
making the getBooks() call needs access to some information (database
name, login etc). In this case, it probably makes sense to create a
new class which handles this whole process.
Sometimes. Looking at JPA, we see that it uses EntityManager to handle
connection details. An object will hold its own EntityManager instance to
access the data store. An EntityManager has instance-level methods to do
things like the 'getBooks()' in this example. Each EntityManager carries its
own state, e.g., connection information. They are not thread safe. If the
query methods of EntityManager were static, the class would be useless.
Sreenivas wrote:
I have a difficulty in understanding Lazy Initialization .
Lazy Initialization:
Lazy Initialization for List<Book> in getBooks() method is like this ,
if i [sic] am not wrong
public List<Book> getBooks()
{
List<Book> books;
Dude, lighten up on indentation. Don't use TABs to indent Usenet listings.
Limit indent levels to, say, four spaces per level, or even fewer.
As Philipp points out, this is a compiler error.
{
books = new ArrayList<Book>();
//Here goes code for making database connection and loading Book
objects
//into ArrayList
}
return books;
}
Philipp wrote:
This won't compile, as your local variable books has not been
initialized. What you probably want to do, is to have a member
Sreenivas, it is a very good practice to compile your examples prior to
posting them on Usenet. That way the only errors will be ones you
intentionally want there. (Sometimes we discuss compiler errors on Usenet, in
which case an example needs to show the relevant errors.)
variable which holds the books, so you can access that variable on
each call of getBooks() (possibly a static Field if you make your call
to getBooks() static, but I think that's a bad idea).
You're right, it's a bad idea.
But, lazy initialization is an optimization. At the point where you
are, optimization is the last thing you should think about. First make
it work, then make it fast (if needed only).
Good point. Also, lazy initialization is rife with danger. It's hard to make
thread safe, and if safe, hard to avoid synchronization slowness if there's a
lot of it.
I've worked on a major project (ca. a million lines of code) where my
predecessors were addicted to unsynchronized lazy initialization of static
variables. That caused major performance bottlenecks, up to tens of seconds
in processes that themselves were on the order of tens of seconds, and
incorrect results.
I recommend that you read a book about Java to get the basic (like
static, member or local vars etc) before going on.
The tutorials, white papers and other material on java.sun.com are a great start.
--
Lew