タグ付けされた質問 「aspect-oriented」

グレッグ・ヤングがKISSに人々に警告するこの講演を見ました：Keep It Simple Stupid。 彼が提案したことの1つは、アスペクト指向プログラミングを行うために、フレームワークを必要としないということです。 彼は強力な制約を作成することから始めます。すべてのメソッドは1つだけのパラメーターを取ります（ただし、彼は部分適用を使用してこのパラメーターを少し緩めます）。 彼が与える例は、インターフェースを定義することです： public interface IConsumes<T> { void Consume(T message); } コマンドを発行したい場合： public class Command { public string SomeInformation; public int ID; public override string ToString() { return ID + " : " + SomeInformation + Environment.NewLine; } } コマンドは次のように実装されます。 public class CommandService : IConsumes<Command> { …

22 c#  aspect-oriented  design-decisions 

誰かがダミーのAOPの概念を説明できますか：ジョインポイント、ポイントカット、織りなど。 例：アスペクト： 複数のクラスにまたがる懸念事項のモジュール化。どういう意味ですか？

19 java  concepts  aspect-oriented  definition 

私はアスペクト指向プログラミングのアイデアに出会いましたが、それに懸念があります。 基本的な考え方は、オブジェクトを使用して十分にモジュール化されていない横断的な懸念を取り、それらをモジュール化することです。それはすべて非常に素晴らしいです。 しかし、AOPの実装は、モジュールの外部からコードを変更することのようです。そのため、たとえば、特定のオブジェクトが関数のパラメーターとして渡されたときに何が起こるかを変更するアスペクトを作成できます。これはモジュールの考え方に直接反するようです。そのモジュールの外部からモジュールの動作を変更することはできません。そうしないと、モジュールのポイント全体が覆されます。しかし、アスペクトはまさにそれをしているようです！ 基本的に、アスペクトはコードパッチの一種のようです。簡単なハックに役立つ場合があります。しかし、一般的な原則として、おそらくあなたがやりたいことではありません。アスペクト指向プログラミングは、私が悪い習慣をとっており、一般的な設計原則に引き上げているように思えます。 AOPは良い習慣ですか？特定のプログラミングの問題はAOPでよりエレガントに解決されますか？

19 aspect-oriented 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 アスペクト指向プログラミングは横断的な関心事に対処することを約束しますが、私はまだ完全に売り切れていません。この問題に対処する他の試みはありましたか？

18 paradigms  aspect-oriented 

これら3つのパラダイムを説明する多くの論文があることは知っていますが、模式的な説明を探しています。 ここにはアスペクト指向プログラミングの非常に良い説明がいくつかありますので、Stack Overflowの人々が配信に慣れているような質の高い答えを得るためにこの質問をしています。

14 paradigms  aspect-oriented  role 

例外処理とログ記録の両方の懸念は、どちらも横断的な関心事であるという点で、ほとんど違いは見られません。どう思いますか？メソッドが実装しているコアロジックとインターリーブするのではなく、単独で個別に処理すべきではありませんか？ 編集：私が言いたいことは、私の意見では、メソッドの実装には実行の成功パスのロジックのみを含める必要があり、例外は他の場所で処理する必要があるということです。これは、チェック済み/未チェックの例外に関するものではありません。 たとえば、言語は次のような構造を使用して、完全にチェックされた方法で例外を処理します。 class FileReader { public String readFile(String path) { // implement the reading logic, avoid exception handling } } handler FileReader { handle String readFile(String path) { when (IOException joe) { // somehow access the FileInputStram and close it } } } 上記の概念言語では、クラスのreadFileが例外をスローしていないため、FileReader handlerがない場合、プログラムはコンパイルされません。そのため、ハンドラーを宣言することで、コンパイラーはハンドラーが処理され、プログラムがコンパイルされることを確認できます。FileReader FileReader このようにして、チェック済みおよび未チェックの例外問題の両方の長所、つまり堅牢性と可読性が得られます。

13 design  exceptions  aspect-oriented 

私は、関数呼び出しのインターセプト、ロギングコードの挿入などを行うためにバイトコードウィービングを使用するJavaやC＃のような言語用に書かれたライブラリについて読んでいます。それらの利用方法をよりよく理解しようとする。マクロについてよく読めば読むほど、マクロがバイトコードウィービングライブラリと同じ種類の機能を提供するように見えます。機能とは、コンパイル時にコードを操作できることを意味します。 私が見ているライブラリの例は、AspectJ、PostSharp、Cecilです。 片方でできること、もう片方ではできないことはありますか？彼らは実際に同じ問題を解決していますか、それともリンゴとオレンジを比較していますか？

11 lisp  clojure  macros  aspect-oriented 

「アスペクト指向プログラミング」または「アスペクト指向ソフトウェア開発」について私が学んだすべてから、それをプログラミングのパラダイムまたは方法論として分類することは不正確であるように見えます。私が言えることから、それはプログラミングの基本的なテクニックではありません。 「パラダイム」と「方法論」の意味を明確にするために、アメリカ遺産辞典の次の定義を参照してください。「オブジェクト指向プログラミング」がどれだけ適切に適用されるか、AOPがどれほど適切に適用されるかを比較します。 パラダイム：特に知的分野において、それらを共有するコミュニティの現実を見る方法を構成する一連の仮定、概念、値、および実践。 方法論：専門分野で作業する、または調査に従事する人々が使用する一連の実践、手順、および規則。作業方法のセット。 「エビデンスに基づく医療」はパラダイムの定義を満たしますが、「子宮摘出術に基づく医療」は問題の空間が狭すぎるため、誤った名称になります。 「指向プログラミング」という接尾辞に基づいて、AOPが「オブジェクト指向プログラミング」と同じようにパラダイムと方法論の両方であると主張しているため、AOPの名前が間違っているかもしれないという印象を受けています。 これらの用語（パラダイムと方法論）はどちらも基本的な手法を示しており、アスペクトについて理解しているのは、狭い問題のスコープを解決するためのテクノロジーであり、Javaの静的変数機能に匹敵するかもしれません。 アスペクトが限られた一連の問題を解決し、AOPが誤称ではない場合は、「継承指向プログラミング」、「依存関係」など、すべてのプログラミング手法に「指向プログラミング」接尾辞を付けるべきではないのは事実です。指向プログラミング」または「スコープ指向プログラミング」

8 development-methodologies  aspect-oriented