Отделение сервисной логики от данных

Я просмотрел пару классов, которые у меня есть в проекте Android, и понял, что смешиваю логику с данными. Поняв, насколько это может плохо сказаться на удобочитаемости и тестируемости -моего проекта, я решил провести некоторый рефакторинг, чтобы абстрагировать всю логику сервисов в отдельные сервисные модули. Однако, поскольку я полагался на полиморфизм Java, я заблудился и нуждаюсь в некотором руководстве.

Предположим, у меня есть этот макет «-быть -измененным» для суперкласса данных и двух подклассов -:

public class DataItem {
    /* some variables */ 

    public saveToDB(/* Some Arguments */) {
        /* do some stuff */
    }

    public render() {
        /* render the class */
    }
}

public class ChildDataItemA extends DataItem {
    @Override
    public saveToDB(/* Some Arguments */) {
        super.saveToDB(); 
        /* more specific logic to ChildDataItemA */
    }

    @Override
    public render() {
        /* render logic for ChildDataItemA */
    }
}

public class ChildDataItemB extends DataItem {
    @Override
    public saveToDB(/* Some Arguments */) {
        super.saveToDB(); 
        /* more specific logic to ChildDataItemB */
    }

    @Override
    public render() {
        /* render logic for ChildDataItemB */
    }
}

. Теперь я подумал о переносе методов saveToDB()и render()в сервисный класс. Однако иногда мне нужно иметь возможность вызывать эти методы в экземпляре скомпилированного типа DataItem, не зная его типа во время выполнения. Например, я мог бы захотеть сделать следующий вызов:

List<DataItem> dataList; 
for (DataItem item: dataList) {
    item.saveToDB();
    item.render();
}

Кроме того, я подумал о следующем:

public class ChildDataItemB extends DataItem {
    @Override
    public saveToDB(/* Some Arguments */) {
        super.saveToDB(); 
        /* more specific logic to ChildDataItemB */
         Service.saveToDBB();
    }

    @Override
    public render() {
        /* render logic for ChildDataItemB */
        Service.renderB();
    }
}

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

Любые идеи о том, как решить эту проблему?

Редактировать :Обратите внимание, что render()и saveToDB()являются просто общими примерами того, какими могут быть эти методы, поэтому проблема на самом деле не в выборе методов, связанных с ORM или SQL.