私はAppDelegate
自分のプログラム全体でオブジェクトを作成して使用しており、すべてのセッターとゲッターを宣言し、データベースのクエリを挿入、選択、削除、更新しています。
そうするのは良い習慣ですか、そうであればどのように、そしてそうでない場合はなぜそれが良い習慣ではないのかを尋ねたいと思います。
私の質問が明確であることを願っています。もしあれば、関連する質問をしてください。
私はAppDelegate
自分のプログラム全体でオブジェクトを作成して使用しており、すべてのセッターとゲッターを宣言し、データベースのクエリを挿入、選択、削除、更新しています。
そうするのは良い習慣ですか、そうであればどのように、そしてそうでない場合はなぜそれが良い習慣ではないのかを尋ねたいと思います。
私の質問が明確であることを願っています。もしあれば、関連する質問をしてください。
AppDelegateを100万のメソッドとプロパティを含む「大きな泥だんご」に変えるのは良い戦略ではありません(魅力的かもしれませんが)。
機能の一部を適切に設計されたオブジェクトに分割するための、より優れたオブジェクト指向のアプローチ-たとえば、すべてのデータベースの相互作用を処理するクラスDatabaseManagerがある場合があります。次に、DatabaseManagerがDatabaseManagerへの参照をアプリデリゲートインスタンスに要求する必要があるアプリのビットがある場合があります。
または、DatabaseManagerへの参照を、それを必要とするアプリの部分に渡すこともできます。ただし、この最後のアプローチでは、「インターフェイスの汚染」がさらに発生します。この場合、DatabaseManagerを渡すために、多くの場所でインターフェイスを変更する必要があります。
さらに別の方法は、DatabaseManager自体を「シングルトン」にすることです。これにより、そのインスタンスは、クラスのクラスメソッドを介してアクセスされます。このように機能するシングルトンは、しばしば眉をひそめますが、通常は正当な理由があります(テストが難しくなる、そのようなこと)。私は、オブジェクトの「シングルトン」の性質をオブジェクトに直接焼き付けることを避ける傾向があります。そのようなものが必要な場合は、既知のアクセスポイント(必要に応じて「ファクトリー」の一種)を使用することをお勧めします。共有インスタンスを取得するために行くことができます。
Appdelegateで処理するのではなく、グローバルシングルトンクラスを作成するのが最善の方法だと思います。
そこですべてのセッターとゲッターを宣言し、プロジェクト全体でシングルトンオブジェクトハンドルを使用します。シングルトンクラスを作成する方法については、このリンクを参照してください
データベースの場合、DataAccessLayerClassを作成します。クエリを実行するときはいつでも、このクラスにアクセスしてください。このクラスメソッドは、データとして入力を持っている必要があり、クエリを作成し、そのクエリを実行してデータを返します。
それはすべて複雑さとあなたの気持ちについてです。あなたはあなたの解決策が好きでなければなりません;-)
私は明らかに別の方法でこれを行います-私はシングルトンを持っています、それは私の一般的なデータベースのものをすべて処理します。アプリケーションデリゲートをできるだけシンプルにしようとしています。コードシェアなどに適しています。