Android プロジェクトにあるいくつかのクラスを見てきましたが、ロジックとデータを混ぜ合わせていることに気付きました。これが私のプロジェクトの可読性とテスト能力にとってどれほど悪いかを認識したので、すべてのサービス ロジックを抽象化してサービス モジュールを分離するためにリファクタリングを行うことにしました。しかし、私は Java のポリモーフィズムに頼ってきたので、道に迷っており、いくつかのガイダンスが必要です。
スーパー データ クラスと 2 つのサブクラスの「変更予定」のレイアウトがあるとします。
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 関連の手法を選択することではありません。