6

90 年代初頭に、私は多くの「エージェント」クラスを含むシステムの設計と実装に参加しました。システムはうまく機能し、適度に保守可能でした。今、私は新しい職場環境で、「オブジェクトは名詞であるべきだ」と主張する人々と議論しています。エージェントが悪い考えである理由を説明する良い記事はありますか? そして、エージェントとオブジェクトをより詳細に区別するものは何ですか (一般的な考えはわかりますが、具体的には何が推奨されていないのでしょうか?)

できれば本全体ではありません。オブジェクト指向ソフトウェアの構築に関する Bertrand Meyer の本を読み始めたところです。それを理解するには時間がかかります。

Tomasz と Niko からのコメントに従って、件名を (記事へのポインターを求めるものから) 変更し、記事へのポインターを提供するのではなく、直接回答するように人々を招待しました。

4

2 に答える 2

4

ウィキペディアによると

エージェント指向プログラミング (AOP) は、ソフトウェアの構築がソフトウェア エージェントの概念を中心とするプログラミング パラダイムです。コアにオブジェクト (変数パラメーターを持つメソッドを提供) を持つオブジェクト指向プログラミングとは対照的 ( http://en.wikipedia.org/wiki/Active_object )

しかし、私は AOP が OOP から分離されているとは考えていません。私は個人的に JADE ( http://jade.tilab.com/、これは FIPA 標準を実装する最も有名なフレームワークの 1 つです ( http://www.fipa.組織) そして、JADE で覚えている限り、エージェントは複雑な機能を実行するために悪用できるオブジェクトを (Java クラスのインスタンスとして) 所有できます。この意味で、エージェントの概念はアクティブ オブジェクトの概念に似ています (http://en.wikipedia.org/wiki/Active_object)。主な違いは、エージェントが提供するサービスの説明をイエロー ページ レジストリで公開し、共有言語 (おそらくオンソロジーに基づく) を介して通信できることです。また、実行中のエージェントがその実行状態を保持したまま別のデバイスに移行できるように、モビリティを提供することもできます。ただし、そのような複雑さはスレッドの上部に実装できるため、オブジェクト指向パラダイムを拡張し、それとは対照的ではありません。

エージェントの概念は、1990 年に Yoav Shoham が人工知能の研究で初めて使用しました。

このリンクhttp://www.infor.uva.es/~cllamas/MAS/AOP-Shoham.pdfで、彼が言うショーハムの出版物の抜粋を見つけることができます

OOP は、計算システムを、相互に通信でき、着信メッセージを処理する個別の方法を持つモジュールで構成されていると見なすことを提案していますが、AOP は、モジュール (現在は精神状態と呼ばれています) の状態 (現在は精神状態と呼ばれています) を修正することによってフレームワークを特殊化しています。エージェント)は、信念(世界、レムセルフ、および他の人に関する信念を含む)、能力、選択、およびおそらく類似の規範と呼ばれる正確に定義されたコンポーネントで構成されます。Compurarion は、これらのエージェントの通知、要求、提供、受け入れ、拒否、競合、および相互の支援で構成されます。この考えは、発話行為に関する文献から直接借用したものです (Grice 1989; Searle 1969; Austin 1962)。

キーワードは、AOPが OOP フレームワークを特化しているということです。だから私が言ったように、それはOOPを拡張します(必ずしも良い方法ではありません). 非常に変化する量のタスクに対処するためにスケーリングする必要がある計算集約型システムを扱う場合、設計と実装に非常に適したこの種のアーキテクチャを使用したいと思うかもしれません。それ以外の場合、AOP はやり過ぎかもしれませんが、それはデザイナー/アーキテクトの感度次第です。

于 2012-08-26T18:53:08.187 に答える
4

OOP とは、状態と関連する動作を一緒にカプセル化することです。

エージェント、マネージャー、およびヘルパーは状態を持たない傾向があります。それらは通常、入力データを操作する一連のメソッドにすぎません。このようなコードには、大量のゲッターとセッターもあります。これは、データ オブジェクトがあまりにも愚かすぎて、それ自体で何もできないためです。これは OOP ではなく、手続き型プログラミングです。

優れた OO 設計は、オブジェクトにデータを要求してから何かを行うのではなく、何をすべきかをオブジェクトに伝えることを中心に展開します。ゲッターを呼び出すときはいつでも、代わりにオブジェクトに直接アクションを実行させることができるかどうか自問してください。たとえば、次のようにする代わりに:

account.setBalance(account.getBalance() + x);

やってみてください:

account.deposit(x);

戦略またはサービス オブジェクトの形でエージェントのようなオブジェクトを使用する状況があることに注意してください。

于 2012-08-26T22:57:35.760 に答える