Здравствуйте уважаемые.
Вопрос больше по проектированию.

Есть классы, которые располагаются в памяти.
MovementUnit -> SeaUnit, EarthUnit
У них естественно все свое.

Теперь есть необходимость извлекать и сохранить эти объекты в БД.
вроде ничего слоджного, сделать 3 таблицы
movement, sea, earth

но потом я ощутил дискомфорт, когда начал делать sql-обертку, типа
DBMovementIUnit, DBSeaUnit, DBEarthUnit

и тут проблема. От какого класса наследоваться? Напрямую от первых классов или от работающего с БД класса(у меня есть еще SqlItem, наделенная возможностью сохраняться удаляться и обновляться).
или вообще, как правильно?

Попробовал наследоваться от SqlItem, больших результатов это не принесло.
если я еще как то выкрутился с созданием SeaUnit и EarthUnit, то если наследники появятся, проблемы будут колоссальные. после чего решил сюда и написать.

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

А может Hibernate поможет?


Быть может не наследоваться, а использовать DB* классы в качестве модели? Разделить объект на модель и контроллер. Класс логики использовать в качестве контроллера. Модель сохранять в БД. Set-тить модель контроллеру, и пусть он с ней работает.

Хух... "белый снег, белый песец - песец ничё не понятно"(с)

А ну давайка подробнейка.

Что за классы, что представляет собой каждый их объект.
Эти классы - походу value objects, просто хранилки данных.
а 
 - это свой скл-враппер поверх чистого джейдибиси(я так понял)

Кого куда и как - просто абзац ничё неясно.

Какие технологии? чистый jdbc?

нет не стоит.

наверно, я делал, DB* инкапсулирует в себе соответствующий класс в памяти.
DB* знает какие поля его соответствующего класса надо сохранять и как их обозвать, фактически формирует SQL-запрос.



Планировалось, что MovementUnit родитель SeaUnit и EarthUnit, они содержат логику работы.
DB* их SQL-оболочки.



Да, все правильно поняли.
Да, использую чистый jdbc.



ну, я до чтения этих постов думал, что не просто value objects, а реализующие определенный интерфейс, т.е.
DBMovementUnit implements MovementUnitInterface
MovementUnit implements MovementUnitInterface
SeaUnitInterface extends MovementUnitInterface
EarthUnitInterface extends MovementUnitInterface
ну и т.д.

но сейчас после чтения поста powerOn, я вижу еще одно неплохое решение, буду пробовать.