問題タブ [abstraction]

カプセル化と抽象化の正確な違いは何ですか？

私の質問は、アプリケーションのモデル層からデータベース接続をどのように抽象化するのですか? 主な関心事は、さまざまな種類のデータベースから簡単に変更できるようにすることです。おそらく、コンマ区切りのフラット ファイル データベースから始めることになるでしょう。次に、SQL データベースに移動します。その後、LDAP 実装の方が優れていると判断します。このようなことを簡単に計画するにはどうすればよいでしょうか。

簡単な例として、名前、姓、電子メールを持つユーザーがいるとします。これを表す非常に単純な PHP クラスは次のようになります (パブリック インスタンス変数の問題は無視してください)。

SQLが埋め込まれたDAOクラスを持っている人をよく見てきました。

このような戦略に関する私の問題は、データベースを変更したい場合、新しいタイプのデータベースに対処するために、すべての DAO クラスの作成、更新、ロード、削除関数を変更する必要があることです。それらを自動生成するプログラムを持っている場合でも (私は特に好きではありません)、このプログラムを編集して機能させる必要があります。

これを処理する方法についての提案は何ですか?

私の現在の考えは、独自の作成、削除、更新、ロード機能を持つ DAO オブジェクトのスーパー クラスを作成することです。ただし、これらの関数は DAO の属性の配列を取得し、クエリ自体を生成します。このように、SQL は複数のクラスに分散するのではなく、SuperDAO クラスにのみ存在します。その後、データベース層を変更したい場合は、SuperDAO クラスがクエリを生成する方法を変更するだけで済みます。利点？短所は？予見可能な問題？良い点、悪い点、醜い点は?

例: スクリプト オブジェクト (文字列、配列など) またはスクリプト エンジン ( eval() 、readFile() など) 間の互換性レイヤー。

したがって、言語が高次の手続きを提供する場合、手続きを返す手続きを使用できます。何かのようなもの：

新しい手順を作成するには、次のようにします。

Proc同様のタスクは、次のように、3 つの引数ではなく 4 つの引数を取る定義を定義し、このプロシージャを呼び出して定義することにより、高次プロシージャをサポートしない言語で実行できますProcA。

では、なぜ高階手続きについてそれほど曖昧なのか? 何か不足していますか？

状態とアクションのペアのユーティリティの内部表現を維持しながら、状態を取り込んでアクションを返すエージェントがあります。また、アクションを取り、状態/報酬のペアを返す環境もあります。

開始状態でエージェントをセットアップし、エージェント -(アクション) -> 環境 -(状態、報酬) -> エージェント -(アクション) -> ... から継続的に移動できるようにする必要がありますが、内部状態は(反復ごとに更新する必要があります) 非公開のままにする必要があります (つまり、エージェントまたは環境内で)。これは、state と action を引数として使用して、エージェント内の関数として environment を単純に呼び出すことができないことを意味します。

私はHaskell初心者なので、これが可能かどうかさえわかりません。

#define基本的に、レガシーディレクティブを抽象化した辞書が欲しいです。

私は6000以上の定義を含む古いヘッダーファイルを持っています。これらはフラグパラメータとして使用され、これらの定義はエンティティの1つのタイプを示しますparameter。

Cで私は持っています

Javaで私は呼び出したい

パラメータは、ライブラリからパラメータを取得することに関連するすべてのロジックをカプセル化します。

パラメーター インスタンスはヘッダーから自動的に抽出され、Java コードに変換されますが、問題はパラメーター クラスが大きくなりすぎることです。つまり、code too largeコンパイル エラーが発生します (下線を引きましょう: 6000 以上のパラメーターがあります)。

IDE がオートコンプリートを使用できるような方法でこの抽象化を行うことができれば非常に嬉しく思いますHashMap。

編集: パラメータ クラスは次のように定義されます。

したがって、1つのオブジェクトに、メッセージの転送先となる一連のデリゲートオブジェクトがあるアプリケーションを作成しています。アイデアは私が言うことができるということです

そして、aMessageはsomeObjectのすべてのデリゲートに送信されます（aMessageの任意の値に対して）。私がこれを行うことができた唯一の方法は、次のようなものです。

それは機能しますが、より良い方法が必要です。このソリューションは、引数を文字列に制限し、単純に醜いです。誰かがメッセージを転送するためのよりクリーンでより良い方法を知っていますか？

ところで、私はsqueakを使用していますが、実装に依存しないソリューションが好まれます;）

編集：デリゲートはオブジェクトと同じクラスであるため、DoesNotUnderstand：をオーバーライドすることはできません。

IRepository<T>インターフェイス、NewsRepositoryクラス、Newsエンティティを用意することで、リポジトリパターンの実装をほぼ完了しました。私が遭遇した問題は、一般的なメソッドを基本リポジトリクラスに抽象化しようとしたことでした。

NewsRepositoryGetメソッドには特定のLinq式が含まれているため、Getメソッドを抽象化する方法が見つかりませんでした。

私の質問は：

1）public T Get(int id)メソッドを基本クラスに抽象化するにはどうすればよいですか？これまで私が行った唯一の方法Expression<Func<T,bool>>は、intの代わりに渡すことですが、各サブクラスはそれぞれの場合でほぼ同じ式を渡す必要があるため、一般的な動作を実際に抽象化することはできません。n => n.id == id。

2） Updateメソッドの基本クラスにサブクラスのGetViolationsとmapメソッドを渡すにはどうすればよいですか？解決策はおそらくデリゲートを使用することだと思いますが、コンパイルする構文を取得できませんでした

これはコードの簡略化されたセットです。実際には、ここに示されている更新だけでなく、更新と挿入を行うSaveメソッドがあります。

Javaでプログラミングするとき、私はほとんどいつも、習慣から外れて、次のように書きます。

ほとんどの場合、それについて考えることさえありません。さて、問題は次のとおりです。常にインターフェイスをリターンタイプとして指定する必要がありますか？または、インターフェイスの実際の実装を使用することをお勧めしますか？使用する場合は、どのような状況で使用しますか？

インターフェイスを使用することには多くの利点があることは明らかです（それがそこにある理由です）。ほとんどの場合、ライブラリ関数がどの具体的な実装を使用するかは重要ではありません。しかし、それが問題になる場合もあるかもしれません。たとえば、私が主にリスト内のデータにランダムにアクセスすることがわかっている場合、aLinkedListは悪いでしょう。しかし、私のライブラリ関数がインターフェイスのみを返す場合、私は単にわかりません。ArrayList安全のために、リストを明示的に：にコピーする必要があるかもしれません。

しかし、それは恐ろしいことのように思われ、私の同僚はおそらく私をカフェテリアでリンチするでしょう。そして当然のことながらそうです。

皆さんはどう思いますか？あなたのガイドラインは何ですか、いつ抽象的な解決策に向かう傾向がありますか、そしていつ潜在的なパフォーマンス向上のためにあなたの実装の詳細を明らかにしますか？

これが何層もの間接化になるのではないかと思っていました。

代替テキスト http://img244.imageshack.us/img244/7371/classdiagram1.jpg

私は少し説明しようとします。アイデアは、Do および Eval メソッドのみを公開する COM オブジェクトの上に API を構築しているということです。

以前は、IComObject を Table クラスに渡して直接処理していましたが、Table クラスをテストしようとすると、IComObject をモックして、コマンドがテーブル クラスの COM オブジェクトに送信されることを心配していました。

基本的な考え方は、COM オブジェクトで適切なコマンドを呼び出す役割を担うコマンド ランナーを用意し、Table (およびその他) オブジェクトはコマンド ランナーと対話するだけで、コマンドが実行されることを心配する必要がないというものです。次に、私のテストでこれを行うことができます：

間接的な層が多すぎますか、それとも問題ありませんか?

注: テーブルだけでなく、Map、Window、Object など、すべてコマンド ランナーと通信するクラスがさらに多くなります。