イディオムとデザインパターンの違いは？

イディオムとデザインパターンの違いは何ですか？これらの用語はどこかで重複しているようです。正確には、私にはわかりません。それらは交換可能ですか？何を使うべきですか？

ここでは C ++イディオムのリストです。それらをデザインパターンと呼ぶことはできますか？

ウィキペディアでは、

低レベルの設計パターンとしてのイディオムのプログラミング

どういう意味ですか？何をしてない「低レベル」ここに意味ですか？

^{この質問は別の質問からインスパイアされています：https : //stackoverflow.com/questions/7343531/are-the-some-design-patterns-language-dependent}

イディオムは、言語の癖を回避するためのアイデアです。思い浮かぶいくつかの例は、元の質問でリンクしたC ++イディオムのいずれかです。彼らはその言語の共通の問題を決まった方法で解決します。

設計パターンはよくある問題を解決するという点で似ています。しかし、理想的な設計パターンは共通の言語機能に基づいているため、言語に依存しません。

ただし、低レベルから高レベルの言語と同様に、イディオムとデザインパターンの間には連続性があります。

Visitorパターンは良い例です。単一の動的ディスパッチのみをサポートする言語が1つしかない場合は、Visitorパターンをその言語のイディオムと見なすことができます。しかし、複数のディスパッチを直接サポートしていない言語の大群があります。したがって、Visitorパターンが生まれました。

Observerパターンも思い浮かびます-C＃はそれを直接サポートしているため、一般的な回避策のパターンは必要ありません。

他の方向に向かう例は、オブジェクト指向機能（継承、ポリモーフィズムなど）です。Cはそれらを直接サポートしていません。より多くの言語がCのようなものである場合、v-tables、type-safetyなどを実装するデザインパターンを開発できます。多くの言語がこれらの機能をサポートしているため、一般化されたCソリューション設計パターン。

通常、デザインパターンは言語固有ではありません。言語イディオムは、言語の特定の機能（または言語のクラス）に依存するか、またはその言語の特定の欠陥を回避する傾向があります。

ウィキペディアの定義にはあまり通貨を入れません。

少なくとも、イディオムは言語固有ですが、デザインパターンは言語にとらわれないように努力する、または努力すべきです。さらに進むと、イディオムは通常、読みやすさを向上させるための慣習であるか、何か技術的な方法が複数ある場合の優れた代替手段です（技術的には）。これらはすべて、アイデアの表現方法（明瞭性、冗長性、簡潔性）に関連していますが、アイデア自体には関連していません。

一方、デザインパターンは、繰り返し発生するアイデアの本質であり、アプリオリは、それに役立つあらゆる言語で表現することができるというアイデアです。Visitorは、シングルディスパッチとオーバーロードに依存するダブルディスパッチの実装であり、これはシングルディスパッチとオーバーロードを持つ任意の言語で使用できます。パターンについて知っていても、表現力豊かなコードや読みやすいコードを書くのに役立ちませんが、関連する問題の解決に役立ちます。たとえばC ++には、Visitorの標準形式がないため、これについて慣用的なことは何もありません。

イディオムの通常の英語の定義。受け入れられている意味が使用されている単語に含まれていないフレーズです。例は、「猫と犬を飼う」または「牛肉はどこですか？」

プログラミング言語では、通常、コード自体からすぐには明らかではないが、他のプログラマが意味を即座に認識するのに十分な頻度で使用される構文上のショートカットを指します。

Perlはおそらく最もイディオムが豊富な言語です。次のような構成体を使用：

while (<IN>) {
    print $_
}

経験豊富なperlプログラマーにとってその意味は明らかですが、他の誰にとっても謎

イディオムは言語固有です。たとえばwhile (*dest++=*src++);、C / C ++イディオムです。PascalまたはJavaでリモートで同様の何かを書くことは完全に不可能です。英語で使用する単語「idiom」を使用します。"ごきげんよう？" 挨拶はイディオムです。ドイツ語やフランス語のようないくつかの言語は同じイディオムを持っています。しかし、他の多くの言語は、このようなことを挨拶として「尋ねる」ことはありません。一方、（オブジェクト指向）パターンは、通常、継承と委任をサポートする任意の言語に適応できます。イディオムは1行のコードと同じくらい簡単かもしれません。設計パターンには常にいくつかのクラスが含まれます。

この記事では、一般的なC ++のイディオムを検索していることがわかりました。最近、かなり深くなってきたため、コードがアマチュアっぽく見えないようにしたいのですが... :-P

Perlでかなりの時間を費やして、私はその言語のイディオムが英語やスペイン語のような自然言語で見られるイディオムに非常に似ていることを発見しました（いくつかのイディオムを十分に知っているのは2つだけです）。

イディオムは「小さなデザインパターン」のようなものではないことに同意します。イディオムは言語の欠陥を回避する方法であるということにはあまり賛成しませんが、そうは思いません。

おそらく、リュック・ダントンの答えが最も近いかもしれませんが、説明させてください。私はイディオムが、まあ、だと思い慣用的な言語を使う人の。通常、共通の表現または一連の表現は、おそらく明白ではありませんが、操作を実行するか、以前にそれを見て十分に流な人に意味のある方法で意図を表現します。

Perlに戻って、おそらく最もよく知られているイディオムは、「シュワルツ変換」、コンパクトで効率的な方法でデータのソートを実行する式です。これはそのような操作を実行する最も明白な方法ではありませんが、簡潔であり、それを以前に見たことがある人はそれが何をしているのかすぐにわかります。

もう1つの注目すべき例は、「The Orcish Maneuver」です。これは、perlのtrue / false、豊富な演算子、および演算子の優先順位の概念を利用しています。

私が個人的にかなり好きなものは、オークの操縦にいくらか関係していますが、その名前は知りません。

push @{ $some_hash{$key} ||= [] }, $some_value;

これは確かに難読化ではなく、それ以外の場合はいくつかの行を取る必要がある何かの明確でコンパクトな表現です。キーがハッシュに存在し、真の値を持っている場合、配列としてそれを逆参照し、その配列に$ some_valueをプッシュします。ハッシュ要素が存在しないか、偽の値を持っている場合、空の配列を割り当て、その配列を逆参照してプッシュを実行します。

Perl 5.14の時点で、このイディオムの一部が廃止されていることにも注意する価値があります。プッシュは配列参照を直接操作できるようになり、@ {}は不要です。また、Perl 5.10の時点では、|| =の代わりに// =を使用できます。これは、真実ではなく定義されているかどうかをチェックします。

イディオムのポイントは、プログラミング言語にまたがるアイデアまたは概念であることです。それは、物事を行う方法であり、低バブルソートのように、一方から取り出してもう一方に貼り付けるときに概念的な再構築なしで機能するプロセスです。デザインパターンは、イディオムの特定の実装、または言語に適合するアイデアの拡張であるため、イベントリスナイディオムなどのjavascriptデザインパターンがあります。

100％確信はありませんが、イディオムは特定の分野に関する用語です。「デザインパターン」と言うとき、「オブザーバーパターン」「責任の連鎖」「訪問者パターン」「工場」を思い浮かべます。これらは、プログラミングの一般的な問題を解決するために使用される一般的なパターンです。包括的なリストはこちらをご覧ください：http : //en.wikibooks.org/wiki/C++_Programming/Code/Design_Patterns

どういう意味ですか？ここで「低レベル」とはどういう意味ですか？

これは、アプリケーションまたはアプリケーションのコンポーネントをモデル化するための高レベルで抽象的な方法ではなく、言語セマンティクスの賢明なまたは一般的な使用法であることを意味します。

たとえば、変数がfalseと評価された場合に変数を設定します（通常、nil変数を条件付きで設定するために使用されます）。

var ||= some_default_value

次に、イベントを処理するためのイディオム（C＃）の例を示します。ハンドラーがアタッチされていない場合、イベントを発生させることはできません。そのため、イディオムは常にこれを最初にチェックすることです。

したがって、イベントを処理するための一般的なイディオムは次のようになります。

EventHandler handler = this.MyEvent;
if ( null != handler ) { handler( param1, param2 ); }

このイディオムは、C＃言語に固有です（排他的ではありません）。

ただし、より一般的には、C＃イベントメカニズムは、任意の言語で実装できるオブザーバーデザインパターンの例です。