One Vs Multiple Objects - Java or any other OOP

Let's say I need to design a system for a collection of books. And let's assume I have millions of books and for simplicity we don't need to add or remove books from the system.

I can create a Book class and initiate an array in the size of the collection:

Book book = new Book[number of books];

In this case, Book would include fields such as:

long bookIsbn
String bookTitle 

Or, instead, initiate just one object:

Book book = new Book();

In this case, the Book class needs to include arrays/lists/maps etc that include info about the entire collection. For example:

Map<Intege开发者_C百科r, String> isbnToTitle = new Map<Integer, String>();

Which representation is more efficient? or maybe to rephrase the question, which is considered as a better OOP approach?

Thanks!

Considering OOP: Think about what a book is and which properties it has. A book definitely does not know about other books, so the second approach is not the way to go.

Arrays... well yes if it is sufficient.
The best thing (from a model perspective) would be to create a class Book and a class e.g. Library that manages all the books. Then the last class contains a list of all books and provides operations on all books.

Separate different concerns:

1) Create a book with its attributes (title, author, etc) and methods (read, shelf, lend, borrow).

2) Create a data structure for storing your books that supports the operations you want (search by author, seach by title, browse, etc)

I don't think the question is informative enough to answer in a good way. OO is, first and foremost, about where to draw the line. If you model a book, and it should have and ISBN, that's fine, but an OO fanatic would also have you equip the Book with an array of Leaf-s, each Leaf having exactly two Page-s, each Page having a PageNumber, and an array of Line-s, each Line being an array of chars. Or maybe a String. But then, a String is not really good OO in this case.

You must take a decision about where to stop modelling, and it is important to realize that you are not modelling the real word, but rather a metaphor negotiationg the mind of the (second) programmer and the machine. What you are doing is at the same time explaining something to the machine and to a reader. OO can be a good tool in this, but it can also be used to obstruct. Be careful! Keep it simple!

If the only thing you need is to lookup a title based on an ISBN, then, keep it simple:

Map<String, String> indexedBookList;

If you suspect that the functionality may grow, you should maybe create a

class Book {
  String title;
  String isbn;
  String author;
}

and keep all your books in a

List<Book> bookList;

Then again, it might be that your project grows from this static little thing into something that has to communicate with an SQL database, that updates occationally and out of your control. Then it might be better, for readability, to keep it simple, and model the database, rather than trying to model the real world.

Programming is about telling a machine what to do, and at the same time telling other people, what we are trying to tell the machine to do. The most important feature in your code, is that it is readable to the programmer that needs to understand it. In a year, that could be you.

It's about what is logical really.

"Book" isn't a logical name for a container that stores a lot of books. You can just model it the way the world does.

And, as you will hear often as a newbie, "efficiency" isn't to be considered (generally) when designing your structures.

You design for correctness, logic, and "meaning". (as well as, obviously, general operation thereof). Efficiency can (typically) come as part of the implementation. It may be such that when you review your design and attempt to implement it, you discover a component won't be efficient. In this case, you attempt to solve that within the context of the overall design, or you adjust the design significantly, based on your findings (this is rare, though).

Neither are correct.

You may want to consider having a Book object (with Title, ISBN code) and a Library (or Bookstore, or Shelf) object with a collection of Book objects.

You don't add "Title and ISBN" to a Book, in real life. You may add a book to a library.

OOP is not necessarily about mimicking real life entities, but your way of doing things is a bit strange and would puzzle anyone reading your code.