Android開発のデザインパターン。 パート4-データの保存。 ドメインモデル、リポジトリ、シングルトンおよびBDD

この記事では、データプロバイダーとの連携方法については説明しません。 これは、ドキュメントとインターネット上の多数の記事の両方に記載されています。
ここでは、ドメインモデル、シングルトン、リポジトリデザインパターン、行動駆動開発（BDD）アプローチ、およびプログラムでのそれらの使用方法について説明します。

ドメインモデルテンプレートは、開発がサブジェクトエリアから行われる場合に使用されます。そのような場合、明確なサブジェクトエリアがあり、その用語は単にバイトで具体化されます。

たとえば、私のプログラムでは、サブジェクト領域は複数のアラームの形式で設定されたスケジュールデータで構成されています。アラームの場合、曜日と時刻、および「アラームがオン」という記号を設定できます。 たとえば、次に機能するアラームと、トリガーされた日時を取得するためのアルゴリズムもいくつかあります。 アラームはスヌーズできるため、スヌーズボタンが使用できなくなった場合、1つのアラームには異なるアクションのトリガーがいくつかあることがわかります。最初のアラーム、スヌーズ、最後のスヌーズです。 したがって、最も近い絶対時間と動作を教えるためのアルゴリズムもあります。
新しい目覚まし時計を作成し、既存のものを編集/削除するためのアルゴリズムもあります。

つまり、私のサブジェクトエリアには、サブジェクトエリアのロジックを実装するいくつかのアラームとアルゴリズムの形式のデータがあります。

なぜこのデザインパターンを使用することにしたのでしょうか。 または、アラームを作成/編集してデータベースに保存する別のクラスを作成し、最も近いアラームを計算するアルゴリズムを別のクラスで作成することもできます。

最初に、サブジェクト領域に関して、1つのアラームのリストを操作し、それに新しいアラームを追加して、どのアラーム時計が次に来るかを尋ねます。 つまり、データとアルゴリズムをカプセル化するという点で便利に見えます。 このようなモデルは、人間の知覚にとってより便利です。

次に、この場合、モデルをテストするときに、通常のユーザーの動作をテストできます。 たとえば、アラームを作成し、スケジュールを設定し、次にモデルが正しい表示をすることを確認してから、新しいアラームを追加し、古いアラームをオフにして、今回は次のアラームが正しいことを確認します。

このアプローチは、行動駆動開発と呼ばれます。 その利点は、サブジェクト領域の観点からモデルをテストできることです。つまり、ユニットテストではユーザーの通常の動作を模倣します。 これは単体テストメカニズムを介して実装されているため、各リリースの前にこれらのテストを実行し、プログラムプログラムが基本的なユーザーアクションを正常に実行できることを確認できます。

アラームの編集/保存に個別のクラスを使用し、最も近いアラームを計算するために個別のクラスを使用した場合、それらを個別にテストすることは確かですが、一緒にチェックすることはできず、ユーザーの基本アクションをチェックすることはできませんでした。

モデルとそのインターフェース

サブジェクト領域を実装するとき、アラームを格納し、これらのアルゴリズムを実装するAlarmListModelクラスの形式でモデルを実装しました。 モデルはデータベースへの保存について何も知らないことを強調したいと思います。 モデルの保存はリポジトリによって行われますが、これについては以下で説明します。

モデルにはアラームのリストがあり、次のアラームの計算時または編集時に使用されます。 つまり、モデルはデータを保存し、アルゴリズムを実装します。 当然、これらのアルゴリズムをアラームクラスに実装することはできません。次回に計算する人は含まれるすべてのアラームについて知っている必要があり、アラームオブジェクトは自分自身についてしか知っていないからです。 したがって、私の目覚まし時計は、データを備えたアルゴリズムのない単純な構造です。

モデルは2つのインターフェイスを実装します。
IAlarmListModel-サブジェクト領域に関連するメソッドを実装します。たとえば、新しい目覚まし時計を作成し、次の操作の時刻を見つけます。
IListModelData-データベースにモデルを保存したり、データベースから読み込んだりするためにリポジトリが使用するインターフェイス。

リポジトリ全体が、データベースからすべてのデータ、読み取り、すべてのアラームのスケジュールを読み取ることに注意してください。 これは、それぞれのデータベースに登るアラームがそれほど多くないという事実と、次のアラームを計算するために含まれるすべてのアラームが必要であり、リストに表示するために一般的にすべてのアラームが必要であるという事実によるものです。

モデルとインターフェイスの主なソースは次のとおりです。

public interface IAlarmListModel { IDisplayAlarm getNextDisplayAlarm(Date curTime); IDisplayAlarm createAlarm(); void updateAlarm(IDisplayAlarm iDisplayAlarm); void addAlarm(IDisplayAlarm iDisplayAlarm); void deleteAlarm(IDisplayAlarm item); void takeAlarmForEdit(int alarmID); IDisplayAlarm getEditingAlarm(); void saveEditingAlarm(boolean stayEditing); } 

takeAlarmForEdit（）およびsaveEditingAlarm（）メソッドは、編集のためにアラームを複製し、ユーザーが「キャンセル」をクリックした場合に行った変更を破棄できるようにするために必要です。 これらのメソッドは、データベースには何も保存せず、アラームの内部リストにのみ保存します。

 public interface IListModelData<T> { ArrayList<T> getItemList(); ArrayList<T> getDeletedItemList(); } 

このインターフェイスは、リポジトリを使用してモデル内の内部アラームリストにアクセスします。 ご覧のとおり、リモートアラームのリストがあります。 これには、ユーザーが削除することを決定したアラームが含まれ、リポジトリはこのリストをスキャンし、データベースからアラームを削除します。

 public class AlarmListModel implements IAlarmListModel, IListModelData<AlarmItem> { private ArrayList<AlarmItem> alarmArray = new ArrayList<AlarmItem>(); private ArrayList<AlarmItem> alarmArrayDeleted = new ArrayList<AlarmItem>(); @Override public synchronized IDisplayAlarm getNextDisplayAlarm(Date curTime) { // ,      . } @Override public synchronized AlarmItem createAlarm() { AlarmItem alarm = new AlarmItem(); alarm.setId(0); //  ,      , //  ID     alarm.setState(EntityState.ADDED); alarm.setName("New alarm");// alarm.setIssue(8, 0, false);//8    alarm.setEnable(true);//  //    // false ,      alarm.setDay(Calendar.MONDAY, true, false); alarm.setDay(Calendar.TUESDAY, true, false); alarm.setDay(Calendar.WEDNESDAY,true, false); alarm.setDay(Calendar.THURSDAY, true, false); alarm.setDay(Calendar.FRIDAY, true, false); alarm.setDay(Calendar.SATURDAY, false, false); alarm.setDay(Calendar.SUNDAY, false, false); return alarm; } @Override public synchronized void addAlarm(IDisplayAlarm item) { AlarmItem alarm = (AlarmItem)item; if(item.getId() > 0) { ex = new Exception("    "); } alarm.setState(EntityState.ADDED); alarmArray.add(alarm); } @Override public synchronized void updateAlarm(IDisplayAlarm item) { AlarmItem alarm = (AlarmItem)item; alarmArray.set(getPositionByID(item.getId()), alarm); } @Override public synchronized void deleteAlarm(IDisplayAlarm item) { AlarmItem alarm = (AlarmItem)item; alarmArray.remove(alarm); alarm.setState(EntityState.DELETED); alarmArrayDeleted.add(alarm); } public synchronized void takeAlarmForEdit(int alarmID) { if(alarmID > 0) editAlarm = ((AlarmItem)getDisplayAlarmByID(alarmID)).clone(); else editAlarm = createAlarm(); } @Override public synchronized AlarmItem getEditingAlarm() { return editAlarm; } @Override public synchronized void saveEditingAlarm(boolean stayEditing) { if(editAlarm == null)return; if(editAlarm.getId() > 0) updateAlarm(editAlarm); else addAlarm(editAlarm); if(!stayEditing)editAlarm = null; } @Override public synchronized ArrayList<AlarmItem> getItemList() { return alarmArray; } @Override public synchronized ArrayList<AlarmItem> getDeletedItemList() { return alarmArrayDeleted; } } 

それでは、モデルの中身を見てみましょう。 リポジトリに関するセクションですべてのメソッドが同期読み取りとしてマークされている理由。

createAlarm（）メソッドを使用するには、モデルを目覚まし時計ファクトリにする必要があります。 ファクトリは、作成されたオブジェクトをアラームの内部リストに追加しないことに注意してくださいaddAlarm（）メソッドがあります

アラームの内部リストを操作するには、addAlarm（）、updateAlarm（）、deleteAlarm（）メソッドが必要です。 既にお気付きのように、AlarmItemクラスには状態を監視するためのメソッドがあり、これらの状態はデータベースに関連するレコードの状態を示します。

 public enum EntityState { ADDED, NOT_CHANGED, CHANGED, DELETED } 

これは、ORMエンジンで使用される標準的な手法であるため、データベースと同期するときに、データベースへの呼び出しの数を減らし、変更されたレコードのみを変更します。
ご理解のとおり、すべてのセッターのAlarmItemクラスは、レコードが変更されたステータスを設定します。 リポジトリはこれらの状態を分析して、データベースで更新する必要があるものとそうでないものを決定します。

addAlarmメソッドでは、1つのトリックを使用しています。 間違った目覚まし時計がコレクションに追加されたときに例外が発生した場合、例外をスローしませんが、この例外をフィールドに静かに保存します。

 ex = new Exception("    "); 

このフィールドは私のテストでチェックされています。 テストが完了すると、このフィールドはヌルになります。そうでない場合、テストは失敗します。 もちろん、Assertを使用するか、例外を完全にスローできますが、例外をスローできない場合があります。 たとえば、クラスがインターフェイスを実装し、メソッドで例外が発生し、インターフェイスでこのメソッドから例外をスローできない場合。 この例外をキャッチするために、テストしたクラスのフィールドに入れて、テストの最後にチェックします。
この問題にはもっとエレガントな解決策があると思いますが、まだ見つかりません。

メソッドtakeAlarmForEdit（）、getEditingAlarm（）、saveEditingAlarm（）は、主に目覚まし時計の編集フォームに必要です。 前述したように、アラームのクローンを作成して変更し、必要に応じて変更を破棄するために必要です。

リポジトリに会う

リポジトリには、モデルの保存と読み取りの2つのメソッドしかありません。

 public interface IAlarmRepository { public abstract void load(); public abstract void save(); } 

ご覧のとおり、モデルについては言及されていません。 私のモデルはシングルトンテンプレートとして実装されます。つまり、プログラム全体でモデルのインスタンスは1つだけであり、プログラムの一部（UIなど）がモデル内の何かを変更し、他の部分（サーバーやリポジトリなど）が同じインスタンスからデータを読み取る場合モデルはすぐに最新の変更を受け取ります。 アプリケーションのパーツ間で既存のオブジェクトのみを転送する必要がある場合に非常に便利です。

シングルトンテンプレートには多くの欠点があります。そのため、アナトマ化され、アンチパターンと呼ばれています。 通常、Singletonは静的クラスを介して実装されるため、テストで模倣できないという事実と、一部のクラスがSingletonを使用する場合、クラス自体の宣言からは見えないという事実につながります。
また、シングルトンをある状態から別の状態に転送するのに2つの呼び出しが必要な場合、シングルトンが常に正しい状態にあることを確認する必要があるという問題もあります。間違った状態で、誤った結果につながる可能性があります。

そこで、この場合はモデルファクトリーであるRoboGuiceを使用しているという事実により、静的クラスの問題を解決しました。 RoboGuiceを使用すると、クラスがシングルトンを使用していることを示すことができ、RoboGuiceを使用して、テストでシングルトンをシミュレーションに置き換えることができます。

正しい状態の問題は、モデルに対するすべての変更がメソッドへの1回の呼び出しで行われ、すべてのメソッドが同期としてマークされるため、同時にモデルへの2つの呼び出しが行われないという事実によって解決されます。

そのため、Singletonは非常に便利です:)。 私のモデルはデータベースから一度ロードされるため、プログラムの実行中は、フォームまたはサービスであっても、各アクティビティでのモデルのロードにリソースを費やす必要はありません。 あるアクティビティから別のアクティビティにデータを転送する方法について考えないでください。 たとえば、編集アクティビティでは、モデルで必要なアラームを見つけるためのIDのみを渡します。

シングルトンを適切に調理する方法を学びましょう。

リポジトリコードは次のとおりです。

 public class AlarmRepository implements IAlarmRepository { // Singleton . //,   Singleton   RoboGuice @Inject private IAlarmListModel alarmListModel; @Inject Context context; @Inject public AlarmRepository() { db = (new DBHelper(context)).getWritableDatabase(); } @Override public synchronized void load() { IListModelData<AlarmItem> res = (IListModelData<AlarmItem>)alarmListModel; res.getItemList().clear(); res.getDeletedItemList().clear(); Cursor c = db.query(DBHelper.TABLE_NAME, projection, null, null, null, null, DBHelper.A_ID); c.moveToNext(); AlarmItem alarm = null; while(!c.isAfterLast()) { alarm = cvToAlarm(c); res.getItemList().add(alarm); c.moveToNext(); } c.close(); alarmListModel.setLoaded(true); } @Override public synchronized void save() { IListModelData<AlarmItem> model = (IListModelData<AlarmItem>)alarmListModel; ContentValues v = null; for(AlarmItem item : model.getItemList()) { switch(item.getState()) { case CHANGED: v = alarmToCV(item); int retVal = db.update(DBHelper.TABLE_NAME, v, DBHelper.A_ID + "=" + item.getId(), null); break; case ADDED: v = alarmToCV(item); int id = (int)db.insert(DBHelper.TABLE_NAME, null, v); item.setId(id); break; case DELETED: ex = new Exception("      DELETED   "); break; } item.setState(EntityState.NOT_CHANGED); } for(AlarmItem item : model.getDeletedItemList()) switch(item.getState()) { case CHANGED: ex = new Exception("      CHANGED   "); break; case ADDED: ex = new Exception("      ADDED   "); break; case DELETED: int retVal = db.delete(DBHelper.TABLE_NAME, DBHelper.A_ID + "=" + item.getId(), null); break; } model.getDeletedItemList().clear(); } } 

cvToAlarm（）メソッドとalarmToCV（）メソッドは、アラームフィールドをデータベーステーブルのフィールドにマッピングしたり、その逆を行ったりするだけで、記事を煩雑にしたくありません。

ここでも、Contenプロバイダーとの連携方法については検討しません。 したがって、あらゆる種類のdb.update（）およびdb.insert（）の意味については、SDKを参照してください。

ここでは、リポジトリのデザインパターンについて説明します。 同期メソッドの宣言という形の二次機能で理解しているように、私のリポジトリもシングルトンです。

リポジトリは、モデルをストレージに保存するためにのみ必要です。 リポジトリは、インターネット上のファイル、データベース、またはサービスです。 その結果、保管方法をモデルから分離し、必要に応じて交換することもできます。
リポジトリはインターフェイスを使用するため、テストでは簡単に模倣に置き換えることができます。 その結果、1つのクラスのみがテストされ、すべての依存部分が模倣に置き換えられたときに単純な単体テストを実行できるだけでなく、機能テストも実行できます。 機能テストでは、いくつかのクラスが一度にテストされます。 原則として、彼らはPresenter、モデルおよび必要な他の補助クラスを取り、Presenterの下のすべてを模倣に置き換えます。 メインのユーザーアクションが正常に処理されることを確認するために、BDD手法を使用してアプリケーションをテストできることがわかりました。

ご覧のとおり、load（）メソッドはアラームテーブル全体を読み取り、モデルに転送します。 また、save（）メソッドは、モデルに保存する必要があるものを調べ、変更されたデータのみを保存します。

PS
この記事は非常に大きなものであることが判明したため、モデルとリポジトリのテストを表示し始めませんでした。 Presenterのテストと比較して、根本的に新しいものはありません。 また、テストでテスト済みクラスのインスタンスを作成し、RoboGuiceを使用して依存関係をシミュレーションに置き換え、結果の死体をテストします。

他の記事を読む

- はじめに
-MVPおよび単体テスト。 ジェダイ・ウェイ
- ユーザーインターフェイス、テスト、AndroidMock
-データの保存。 ドメインモデル、リポジトリ、シングルトンおよびBDD
-サーバー側の実装、RoboGuice、テスト
-小さなタスク、設定、ロギング、ProGuard