タグ付けされた質問 「extensibility」

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 Lispの知識は限られています（暇なときに少し学ぼうとしています）が、Lispマクロを理解する限り、Lisp自体で記述することで、新しい言語構造と構文を導入できます。これは、Lispコンパイラ/インタプリタを変更せずに、新しい構成をライブラリとして追加できることを意味します。 このアプローチは、他のプログラミング言語のアプローチとは大きく異なります。たとえば、Pascalを新しい種類のループまたは特定のイディオムで拡張する場合、言語の構文とセマンティクスを拡張してから、コンパイラにその新しい機能を実装する必要があります。 Lispファミリー以外のプログラミング言語（Common Lisp、Scheme、Clojure（？）、Racket（？）など）以外に、言語内で言語を拡張する同様の可能性を提供するプログラミング言語はありますか？ 編集 長時間の議論を避け、答えを具体的にしてください。何らかの方法で拡張できるプログラミング言語の長いリストの代わりに、概念的な観点から、拡張メカニズムとしてのLispマクロに固有のものと、どの非Lispプログラミング言語がいくつかの概念を提供するかを理解したいそれは彼らに近いです。

20 lisp  extensibility  macros 

何らかのアプリケーションがあり、ユーザーがプラグインを作成できるようにしたい場合、アプリケーションをどのように設計する必要がありますか？ 何を考慮に入れる必要がありますか、これにはどのようなデザインパターンがありますか？

20 design  plugins  extensibility 

ASP.NET MVC 4を使用して従業員イントラネットシステムを構築する計画段階にあります。このサイトは、メッセージング、給与の変更など、異なる機能を提供する個別の「モジュール」で構成されています。 。これらのモジュールをコンパイル時に有効または無効にできるようにしたいと思います。ホームページには、ロードされた各モジュールにリンクするナビゲーションが表示されます。 これまでは簡単ですが、ナビゲーション機能がモジュールについて事前に知る必要はありません。言い換えれば、モジュールを動的に検出できるようにします。新しいモジュールのコードを記述し、ソースの他の場所でコードを変更せずにナビゲーションバーにリンクを追加できるようにしたいのです。各モジュールには、ナビゲーションバーに自分自身を登録する何らかの方法が必要です。さらに重要なことですが、これは、ロードされた各モジュールに対して行う必要があります。 MVCのエリアはサイトのレイアウトが事前にわかっている場合のために設計されているため、MVCのエリアを使用することはできません。MEFは適切であると思われますが、MEFとMVCを組み合わせることに成功した人はいませんでした。MEFは実際にここに行く方法ですか、それとも私が必要なことを達成するためのより良い方法がありますか？

14 design-patterns  asp.net-mvc  extensibility  mef 

注：ここでコーディングのヘルプは必要ありませんProgrammers。理由があります。Javaの（単なる）理解ではなく、プログラムの計画/作成スキルを向上させたい。 ここでこのLARPゲームのスキルに基づいて、任意のカテゴリシステムを持つツリーを作成する方法を見つけようとしています。私の以前の試みは、スキルがカテゴリーでもあったかどうかについては愚かでした。それをコーディングしようとするのは面倒でした。自分のツリーを描くと、自分の「葉」だけがスキルであることに気付き、他のカテゴリにはカテゴリとしてラベルを付けました。 私が望んでいるのは、モデルとビューを分離しようとするツリーを作成し、任意の親に任意のタイプの子ノードを（編集/レンダリングの別の方法で）追加できるようにする方法です。 NBここにあるものはすべて、財産のように思える場合でも、スキルとして購入されます。エンドユーザーは、これを購買スキル（紙のATMで行う）と見なすため、同じページにすべて表示する必要があります。 ツリーの説明：ツリーは、ハードコードされた最高レベルのカテゴリ（武器、物理的および精神的、医療など）のセットで「生まれ」ます。このことから、ユーザーはスキルを追加できる必要があります。最終的に、彼らは「片手剣専門化」スキル（アイテムではない）を追加したいと考えています。そのためにはWeapons、選択One-handedした状態で「追加」をクリックし、その子に表示されるコンボボックスノードから選択し、もう一度追加をクリックして、表示されるその子ノードのテキストフィールドに名前を入力します。次に、もう一度追加をクリックして、そのリーフの「レベル」または「ティア」を追加/指定します。最初に習熟し、次に専門化（例えば）。 もちろん、別のスキルを購入する場合は、リーフへの完全に異なるルートです。武器の例で行ったように、ツリーの同じレベルにコンボボックスは必要なく、その背後にある他のロジックも必要になる場合があります。これは、プログラミングは言うまでもなく、頭を悩ませている問題です。一連のクラスを作成し、それらをどの順序でアタッチするかを指定せずに、すべてを適合させる方法。 この種のツリーをコードで記述するのに適したシステムは何ですか？私が見た他のすべてのJTreeの例には、予測可能なパターンがありますが、私の場合はそうではありません。これをすべて「リテラル」でコーディングする必要はありません。どのタイプ（コンボボックス、テキストフィールドなど）の子ノードの長いリストをどの親で許可する必要があります。抽象クラスを使用する必要がありますか？インターフェース？ 上にリストされていない、異なる動作をする他のスキルを追加するときに、この種のオブジェクトのクラスターを拡張可能にするにはどうすればよいですか 使用する適切なシステムがない場合、この種のことを行う方法を決定するための適切なプロセスはありますか？ 私の頭の中の歯車が回っています： 私はいつもする必要があります： 親を確認する 親に基づいてオプションを提供する 私はこの共通性のskillために、スキルとカテゴリの一般的なメソッドを定義/概説する何らかの抽象/インターフェイスクラスが必要だと考え始めています。（できれば）ルールとオプションをデータベースに入れて、そこから読み込めます。問題は、抽象メソッドまたはインターフェイスメソッドと、それを実装する方法との間の問題です。

12 planning  trees  extensibility 

私はジェネリックスを利用するコードをいくつか開発しています。私の指針となる原則の1つは、今日だけでなく、将来のシナリオでも使用できるようにすることでした。ただし、いくつかの同僚は、拡張性のために読みやすさを犠牲にしている可能性があると述べています。これを解決するために考えられる方法についてフィードバックを集めたかったのです。 具体的には、ここに変換を定義するインターフェースがあります。まず、項目のソースコレクションから開始し、各要素に変換を適用して、結果を宛先コレクションに保存します。さらに、宛先のコレクションを呼び出し元に返すことができるようにしたいのですが、コレクションの参照を使用するように強制するのではなく、宛先のコレクションに実際に提供したコレクションの種類を使用できるようにしたいと思います。 最後に、宛先のコレクション内のアイテムのタイプが、ソースのコレクション内のアイテムのタイプと異なるようにすることができます。これは、おそらく変換が行うためです。たとえば、私のコードでは、変換後にいくつかのソース項目が1つの宛先項目を構成しています。 これにより、次のインターフェースが生成されます。 interface Transform<Src, Dst> { <DstColl extends Collection<? super Dst>> DstColl transform( Collection<? extends Src> sourceCollection, DstColl destinationCollection); } インターフェースを適切にスーパータイプとサブタイプで使用できるようにするために、私はすべてがうまくいってJosh BlochのPECS原則（プロデューサー拡張、コンシューマースーパー）を適用しようとしました。最終結果は幾分怪物です。 さて、このインターフェースを拡張して、どういうわけかそれを特化できればいいのですが。たとえば、ソースアイテムのサブタイプとデスティネーションアイテムのスーパータイプをうまく使用する必要がない場合は、次のようにします。 interface SimpleTransform<Src, Dst> { <DstColl extends Collection<Dst>> DstColl transform( Collection<Src> sourceCollection, DstColl destinationCollection); } しかし、Javaでそれを行う方法はありません。私はこのインターフェースの実装を、恐怖で走るのではなく、他の人が実際に行うことを検討するようなものにしたいと考えています。私はいくつかのオプションを検討しました： 宛先のコレクションを返さないでください。変換を実行しても何も返されないことを考えると、奇妙に思えます。 このインターフェイスを実装する抽象クラスがありますが、パラメーターを使いやすいものに変換し、より単純なシグネチャを持つ別のメソッド "translateImpl（）"を呼び出します。これにより、実装者の認識の負担が少なくなります。しかし、インターフェイスをユーザーフレンドリーにするためだけに抽象クラスを作成しなければならないのは奇妙です。 拡張性を忘れ、よりシンプルなインターフェースを備えています。おそらく、それを宛先のコレクションを返さないことと組み合わせます。しかし、それは将来の私の選択肢を制限します。 どう思いますか？使用できるアプローチがありませんか？

8 java  readability  generics  extensibility