Один против нескольких объектов - Java или любой другой ООП - PullRequest
2 голосов
/ 02 марта 2010

Допустим, мне нужно разработать систему для коллекции книг. И давайте предположим, что у меня есть миллионы книг, и для простоты нам не нужно добавлять или удалять книги из системы.

Я могу создать класс Book и создать массив размером с коллекцию:

Book book = new Book[number of books];

В этом случае Book будет включать такие поля, как:

long bookIsbn
String bookTitle 

Или вместо этого инициировать только один объект:

Book book = new Book();

В этом случае класс Book должен включать массивы / списки / карты и т. Д., Которые включают в себя информацию обо всей коллекции. Например:

Map<Integer, String> isbnToTitle = new Map<Integer, String>();

Какое представление более эффективно? или, может быть, перефразировать вопрос, который считается лучшим подходом ООП?

Спасибо!

Ответы [ 5 ]

12 голосов
/ 02 марта 2010

Учитывая ООП: Подумайте о , что книга есть и какие свойства она имеет. Книга определенно не знает о других книгах, поэтому второй подход - , а не путь.

Массивы ... ну да, если этого достаточно.
Лучше всего (с точки зрения модели) было бы создать класс Book и класс, например. Library, который управляет всеми книгами. Затем последний класс содержит список всех книг и предоставляет операции со всеми книгами.

2 голосов
/ 02 марта 2010

Я не думаю, что вопрос достаточно информативен, чтобы дать хороший ответ. ОО, в первую очередь, о том, где провести черту. Если вы смоделируете книгу, и она должна иметь и ISBN, это нормально, но фанатик ОО также попросил бы вас снабдить Книгу массивом Листов, каждый Лист имеет ровно две Страницы, каждая Страница имеет PageNumber, и массив строк-s, каждая строка представляет собой массив символов. Или, может быть, строка. Но тогда String не очень хороший OO в этом случае.

Вы должны принять решение о том, где прекратить моделирование, и важно понимать, что вы моделируете не реальное слово, а скорее согласование метафоры в уме (второго) программиста и машины. То, что вы делаете, - это одновременно что-то объяснять машине и читателю. ОО может быть хорошим инструментом в этом, но он также может быть использован, чтобы помешать. Быть осторожен! Сохраняйте это простым!

Если единственное, что вам нужно, это поиск заголовка на основе ISBN, то сделайте это просто:

Map<String, String> indexedBookList;

Если вы подозреваете, что функциональность может возрасти, вам, возможно, следует создать

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

и храните все свои книги в

List<Book> bookList;

С другой стороны, может случиться так, что ваш проект вырастет из этой статичной мелочи в нечто, что должно взаимодействовать с базой данных SQL, которое обновляется время от времени и выходит из-под вашего контроля. Тогда для удобства чтения было бы лучше сохранить простоту и моделировать базу данных, а не пытаться моделировать реальный мир.

Программирование заключается в том, чтобы сообщать машине, что делать, и в то же время рассказывать другим людям, что мы пытаемся сказать машине, чтобы делать. Наиболее важной особенностью вашего кода является то, что он доступен для чтения программисту, который должен это понимать. Через год это может быть ты.

2 голосов
/ 02 марта 2010

Отдельные вопросы:

1) Создайте книгу с ее атрибутами (название, автор и т. Д.) И методами (чтение, полка, одолжить, одолжить).

2) Создайте структуру данных для хранения ваших книг, которая поддерживает нужные вам операции (поиск по автору, поиск по названию, просмотр и т. Д.)

1 голос
/ 02 марта 2010

Речь идет о том, что действительно логично.

«Книга» не является логическим именем для контейнера, в котором хранится много книг. Вы можете просто смоделировать это так, как это делает мир.

И, как вы часто будете слышать, как новичок, «эффективность» не должна учитываться (как правило) при проектировании ваших конструкций.

Вы разрабатываете правильность, логику и «смысл». (а также, очевидно, общая их деятельность). Эффективность может (как правило) быть частью реализации . Это может быть так, что когда вы просматриваете свой дизайн и пытаетесь реализовать его, вы обнаруживаете, что компонент не будет эффективен . В этом случае вы пытаетесь решить эту проблему в контексте общего проекта или существенно корректируете проект, основываясь на своих выводах (хотя это редко).

0 голосов
/ 02 марта 2010

Ни то, ни другое не верно.

Возможно, вы захотите иметь объект Book (с названием, кодом ISBN) и объект Library (или Bookstore, или Shelf) с коллекцией объектов Book.

Вы не добавляете "Заголовок и ISBN" в Книгу в реальной жизни. Вы можете добавить книгу в библиотеку.

ООП не обязательно подражает сущностям реальной жизни, но ваш образ действий немного странен и может озадачить любого, кто читает ваш код.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...