私は最近、「アンチパターン」と呼ばれる「神オブジェクト」という用語に出くわしました。悪いコーディング慣行について聞いたことがありますが、そのように説明されていることは聞いたことがありません。
そこで、ウィキペディアにアクセスして詳細を調べたところ、 「ラビオリコード」と呼ばれるアンチパターンがあり、「多数の小さく（理想的には）緩く結合されたソフトウェアコンポーネントによって特徴付けられる」と説明されていることがわかりました。
私は困惑しています-なぜこれが悪いことなのですか？
15586 次
8 に答える
36
スパゲッティ：
スパゲッティコードは、ソースコードの蔑称的な用語です
ラビオリ：
Ravioliコードは、コンピュータープログラム構造の一種であり、多数の小さく（理想的には）緩く結合されたソフトウェアコンポーネントを特徴としています。この用語はスパゲッティコードと比較しており、プログラム構造をパスタと比較しています。
それらを比較しています。アンチパターンだと言っているのではありません。
しかし、私は同意します。記事は紛らわしいです。問題は、ラビオリのアナロジーではなく、ウィキペディアの記事の構造自体にあります。それは悪い習慣としてスパゲッティを呼び始め、次にいくつかの例を言い、その後ラビオリコードについて何かを言います。
編集：彼らは記事を改善しました。アンチパターンであるため
結合と凝集の観点からは一般的に望ましいことですが、コードの過度の分離とカプセル化は、コールスタックを肥大化し、メンテナンス目的でコードをナビゲートすることをより困難にする可能性があります。
于 2010-01-12T20:18:41.863 に答える
18
ラビオリコードとラザニアコードはどちらも蔑称的な用語であり、パスタの直喩である「スパゲッティコード」と一緒に意図的に配置されており、どちらの用語も現実世界のアンチパターンを表しています。一部のコードは、保守に非常に時間がかかり、非常に多くの個別のサブプロセスに分割されているという理由だけで失敗する傾向があります。これがラビオリコードです。一部のコードには非常に多くの抽象化レイヤーがあるため、変更を実装したり、障害が発生しているレベルを理解したりすることが非常に困難になります。つまり、ラザニアコードです。ラザニアコードに変更を加える唯一の実用的な方法は、多くの場合、単にレイヤーをバイパスして、その仕事を行う簡単なコードを書くことです。私はいくつかのラビオリコードを維持する必要がありますが、一般的にそのようなコードはその畳み込みに苦しんでおり、広く使用されていることを見つけることができません、ですから、私たち全員が精通している例はほとんどありません。対照的に、ラザニアコードは現在どこにでもあります。私は自分でパスタコードを書いていないと思うのが好きですが、少なくともスパゲッティの文字列をたどることはできます...
于 2015-12-07T12:53:58.667 に答える
16
スパゲッティコードのページに記載されていますが、それが悪いことではありません。これは関連する用語であり、独自のページを持つほど重要ではないためです。
それの悪い面に関して、グーグルはhttp://developers.slashdot.org/comments.pl?sid=236721&cid=19330355でコメントをします：
問題は、それが真の一貫性のない関数（メソッドなど）につながる傾向があり、非常に多数の関数に散在する非常に単純なものでさえ実装するコードを残すことが多いことです。コードを維持する必要がある人は、すべてのビット間のすべての呼び出しがどのように機能するかを理解する必要があり、GOTOの代わりに関数呼び出しを除いて、スパゲッティコードのほとんどすべての欠点を再現します。..。
あなたはそれが合理的であるかどうかを判断しなければなりません:)。
于 2010-01-12T20:21:24.200 に答える
8
Pretty much the only reason "ravioli code" has survived as a phrase is because programmers have an innate sense of humor. Try as I might - and believe me, I've tried - it's really hard to come up with an example of object oriented code that was both (a) packaged such that it was really hard to navigate in the same meta-sense that "spaghetti code" is hard to navigate, and (b) reflected a frequent anti-pattern in coding practice.
The best example of "ravioli code" I can come up with is a multitude of classes, each tightly packaged, but where it's really hard to dig out where the main flow of execution is. Neural network applications might exhibit this, but that's sort of the point. A more mundane example would be UI code that is very heavily event-oriented, but again, it's hard to go overboard with that - if anything, most UI code isn't event-driven enough.
于 2010-01-12T20:27:44.170 に答える
5
問題は、さまざまな人々が「ラビオリコード」という用語をさまざまな意味で使用していることです。
適度に小さいコンポーネントの適度な数が適切です。全体的な構造がはっきりしない小さなコンポーネントの巨大な山はそれほど良くありません。
緩く結合されたコンポーネントが適しています。ゆるく結合しているように見せるために相互依存関係を隠すコンポーネントはあまり良くありません。
異なるコンポーネント間の関係を確認できることは、実際には良いことです。
ただし、ほとんどのコードベースには逆の問題があるため、通常、モジュール性を高めることは良いことです。ほとんどの人は悪い意味で「ラビオリコード」を見たことがないと思います。実際には、それはみじん切りのラビオリ（モジュールであるべきものが複数の「モジュール」に分割されている場合-どれもそれ自体では意味がありませんが、対応する他の部分との組み合わせでのみ）、またはラビオリのように見える傾向があります十分な水なしで調理された（そのため、「モジュール」の巨大な塊がすべてくっついてしまう）。
TODO：「Helloworld」プログラムを最大100モジュールとして記述して、過モジュール性を示します。
TODO2：トラックに積まれたラビオリから橋を架けて、最適ではない構造的特徴を示してみてください。
于 2016-07-28T21:49:53.107 に答える
4
すべてのプロジェクトのすべてのクラスを何らかの理由で緩く結合する必要があるという独断的なルールを適用すると、多くの潜在的な問題があることがわかります。
実際に価値を追加することなく、完全に優れたアプリケーションをますます緩く結合しようとして、ホイールを回転させることができます。
ただし、急いで付け加えておきますが、私たちは皆、緩く結合されたクラスやコンポーネントなどを目指すべきだと思います。
于 2010-01-12T20:21:52.810 に答える
3
必ずしもそうとは限りませんね。ウィキペディアの記事では、それが悪いとは説明されていません。これらのコンポーネントのサイズと数が問題のドメインに関連して適切である、いくつかの緩く結合されたソフトウェアコンポーネントは、私にはかなり理想的に聞こえます。
実際、ラビオリコードの他の定義を調べると、それが理想的なソフトウェアデザインパターンとして記述されていることがわかります。サイズと数が適切である必要があるという警告が依然として必要です。
于 2010-01-12T20:16:43.103 に答える
2
記事を読むと、スパゲッティはアンチパターンです。しかし、ラビオリとラザニアはアンチパターンではありません。
于 2010-01-12T20:18:48.807 に答える