6

「どのJSライブラリを使用していますか」という投票でこのコメントを見たばかりです

「@Xanti-はい、はい、プログラミングにおけるモジュール化と抽象化はひどい習慣です。他の関数を呼び出す関数？無駄です。」

PHP用のKohanaフレームワークとjavascript用のJqueryライブラリを使用しているので、それは私に興味をそそられました。

なぜ一部の人々は抽象化とモジュール化の悪い習慣を考えるのですか？フレームワークとライブラリは、開発を容易にし、スピードアップするために作られていませんか？

ここに投票へのリンクがあります

4

8 に答える 8

11

抽象化が多すぎると、生産性に悪影響を与える可能性があることがわかりました。

  • 抽象化が適切に選択されていないと、抽象化がまったく行われない場合よりも悪くなる可能性があります。

  • 単純なアルゴリズムがどのように機能するかを理解するために4つまたは5つの異なるモジュールを読む必要がある場合、抽象化の障壁はおそらく適切な場所にありません。コードをリファクタリングする良い方法があるかもしれませんし、障壁を取り除くだけの方が簡単かもしれません。

  • 抽象化が比較的馴染みのあるアイデアに対応していない場合、新しいチームメンバーが学ぶのは難しいかもしれません。

抽象化は「無知な善」ではありません。特定の目的を果たすために存在します。最も一般的な目的の中には

  • データ構造の不変条件を保護するため

  • 変更される可能性のある設計上の決定をカプセル化する

抽象化が邪魔になった私の最大の経験は、C用のリサーチコンパイラでした（2008年のアーカイブスナップショットhttps://www.cs.tufts.edu/~nr/c--/）。学生がコンパイラのクラスで見慣れていたよりもはるかに多くの抽象化がありました。

  • ターゲットマシンは抽象的でした
  • アセンブリ言語は抽象的でした
  • 呼び出し規約は抽象的でした
  • スタックフレームレイアウトは、通常とは異なる「ブロック」抽象化を使用していました

これらの抽象化のそれぞれが私たちの研究にとって重要な目的を果たしましたが、全体的な効果は、新入生がコンパイラーを学ぶのが非常に困難であったということでした。そのため、元のコメントが冗談であったとしても、抽象化が問題を引き起こす可能性がある場所があります。

于 2010-02-26T01:33:28.457 に答える
3

限られたリソースで作業する場合、オーバーヘッドが簡単に追加される可能性があります。

コンパイラが最適化するものは確かにありますが、4つのきちんとした.cファイルに4つのきちんとしたオブジェクトを作成し、それらを4つのきちんとした.soファイルにコンパイルしてから、ダムリンカー、簡単にインライン化できるクロスモジュール関数呼び出しでリンクします。まだ完全な状態のダンプで作成されており、完全に最適化できる部分は引き続き実行されます。

オブジェクト指向言語のベストプラクティスを使用し、高度なデザインパターンを使用し、複数の抽象化レイヤーを作成して、4KRAMと16Kフラッシュを備えた8ビットPICマイクロコントローラーのプログラミングを開始すると、プログラムは実行されません。「時期尚早の最適化はすべての悪の根源です」と、128バイトのRAMを搭載したプラットフォーム用にプログラムしたことのない人が言いました。

于 2010-02-26T15:47:13.940 に答える
1

コメント投稿者は真面目ではなかったと思われます。

モジュール化と抽象化が悪い習慣であり、実際にそれを意味していると主張する人は誰も想像できません。

于 2010-02-26T00:29:49.407 に答える
1

一般に、抽象化とモジュール化は優れており、不可欠です。そこに悪い抽象化があるかもしれません、例えば：もはやサポートされていないか、高価であるか、単に使用できないか、大きいか、時代遅れであるか、または第2の選択肢など。図書館の「市場」は一般的に巨大です。どの種類のライブラリを使用しているかは、状況や個人的な好みによって異なります。

なぜ一部の人々は抽象化とモジュール化の悪い習慣を考えるのですか？フレームワークとライブラリは、開発を容易にし、スピードアップするために作られていませんか？

変化と学習は時々難しいので、人々はそれと戦います。この種の研究が好きな場合は、次のURLから調査を開始できます。http：//thedailywtf.com/ :-)私はそれらを無視し、ライブラリとフレームワークを使用して、プログラマーの生活を向上させます。

于 2010-02-26T01:01:56.487 に答える
1

開発者は、抽象化またはモジュール化が、その抽象化またはモジュール化と相互作用することができ、または必要であり、その目的または設計を理解できない場合、抽象化またはモジュール化は悪い習慣であると主張します。

于 2010-02-26T01:44:27.203 に答える
0

すべての関数（およびヘルパー関数）が独自のモジュールにある場合はどうなりますか？

于 2010-02-26T00:30:55.807 に答える
0

しばらく前は静かでしたが、Fortranコンパイラのマニュアルでは、同じ長さの文字列とランダムに選択された文字として識別子を選択することを推奨していました。

説明？これにより、内部コンパイラのハッシュテーブルで名前を均等に分散できるため、コンパイルが高速化されます。

あなたが引用しているテキストは、この推奨事項のすぐ隣にあると思います

于 2010-02-26T01:20:02.003 に答える
0

優れた抽象化が頻繁に使用されます

優れた抽象化は、ソフトウェアの2つ以上の場所で参照されます。

例：

  • 2+コールサイトで機能します。
  • 2つ以上の具象クラスを持つ抽象クラス。
  • 2+実装とのインターフェース。
  • 2つ以上のインスタンス化を持つジェネリック
  • 2人以上のユーザーがいるライブラリ。
  • 等

2つ以上の場所で参照される抽象化は、一般的なものを除外することにより、コードサイズを削減するのに役立ちます。これは、良いことです。

ただし、一度だけ参照される抽象化が多数ある場合は、抽象化が不要である可能性が高くなります。

不要な抽象化が発生した場合のいくつかの例：

  • オブジェクトハッピーコードの記述（実装または具体化が1つしかないあらゆる場所のインターフェースと抽象クラス）。これらのインターフェースと抽象クラスは必要ありません（開発のその時点で）。YAGNIの原則。
  • 誰かが古いインターフェースの上に「光沢のある新しい」インターフェースを構築します。変換後の新しい関数は、古いインターフェースのみを呼び出します。これを数回繰り返すと、大きな混乱が生じることが想像できます。この場合、古い関数には単一の呼び出しサイトがあるため、これらは必要ありません。コードを古い関数から新しい関数に移動する必要があります。または、新しい関数を記述して古い関数を変更しないでください。

本当に良い抽象化のいくつかの例：

  • ハードウェア抽象化レイヤー：アプリケーションに単一のインターフェイスを提供するため、アプリケーションはハードウェアの種類ごとにコードを開発する必要がありません。
  • ファイルシステム：FAT、NTFS、EXT3を使用してもかまいません。それはあなたがファイルとディレクトリを使うことを可能にします、ファイルシステムドライバは残りをします。
  • C言語：CPUアーキテクチャごとにプログラムを移植する必要はありません。コンパイルするだけです。

したがって、あなたの質問に実際的に答えるには、抽象化は2か所未満から参照されている場合は良くありません。

モジュール化に関しては、主観的です。コードを好きなように整理できます。ライブラリのソースコードが単一のソースファイルに含まれている場合、数百のファイルを爆発させた場合よりも悪化することはありません。

抽象化を良いか悪いかを評価するときは、常に全体像を考慮してください。プロジェクト全体、製品ライン全体などです。

于 2014-02-26T16:03:01.720 に答える