Почему мы используем базовые классы в Java - PullRequest
2 голосов
/ 21 июля 2011

При выполнении дизайна / каркаса обычной практикой является наличие базового класса для объектов-значений, служб, DAO и т. Д. Например, если мы создаем новый VO, он расширяется от этого BaseVO.Если мы создаем новый DAO, он должен расширяться от BaseDAO.По какой причине у нас такой базовый класс?

Ответы [ 7 ]

5 голосов
/ 21 июля 2011

Ответ очевиден;) Потому что легко добавлять общие функции или логику для всего приложения.

Например, если вы всегда хотите сохранить дату создания и дату модификации для ваших стоимостных объектов. Или предоставьте вспомогательные методы для подключения к базе данных в службах.

1 голос
/ 21 июля 2011

Примером того, что BaseDAO может сделать для всех своих подклассов, будет настройка или получение соединения с базой данных. Было бы довольно неудобно помещать один и тот же код в AppleDAO, PearDAO и BananaDAO (в случае, если вы хотите сохранить в своей БД Apple, Pear и Banana).

Если вы поместите код для подключения к БД во все из них, вам придется изменить их все, например, когда ваш хост базы данных изменится. Если он в суперклассе, вам нужно изменить его только в одном месте.

1 голос
/ 21 июля 2011

Наследование вместе с инкапсуляцией и полиморфизмом является одной из трех основных характеристик объектно-ориентированного программирования.Наследование (наследование базового класса) позволяет создавать новые классы, которые повторно используют, расширяют и изменяют поведение, определенное в других классах.

Легко добавить общие методы и свойства в базовый класс.Но это не правильный путь для всех случаев.Шаблоны проектирования (например, Шаблон стратегии ) используют вышеупомянутые концепции ООП для реального проектирования.

0 голосов
/ 21 июля 2011

BaseDAO будет состоять из общих методов, которые будут использоваться в последующих классах, или вы также можете определить абстрактный метод, который должен быть реализован как поведение, которое должен иметь весь расширенный класс.

0 голосов
/ 21 июля 2011

Я однажды услышал предложение и процитировал его здесь:

small programs have a funny way of getting bigger quickly.

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

0 голосов
/ 21 июля 2011

Существуют определенные функции или поля, которые иногда необходимо сохранять при расширении фреймворков.Давайте возьмем простой пример.Если у нас есть Животное с именем и способностью говорить (да, школьный пример, но со мной голый), то все, что является животным, должно иметь эти вещи.Так, скажем, у нас есть кошка, очевидно, что кошка не говорит то же самое, что и собака, поэтому оба из них обладают способностью говорить () и дают 2 разных результата.

В вашем случае это также делаетдля расширяемых и взаимозаменяемых систем, так что вы можете менять слои без необходимости перезаписывать большие части кода (иногда вам даже не нужно ничего менять).

0 голосов
/ 21 июля 2011

Хорошей практикой является наличие родительского класса, чтобы поведение и элементы данных, применимые ко всем дочерним дочерним элементам, могли перемещаться вверх по дереву наследования.

Например:

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