私たち全員が知っているように、非常に基本的なソフトウェアエンジニアリングの原則は緩い組み合わせです。しかし、私たちは、UNIXに似たオペレーティングシステムのプログラムが高度に結合されていることを知っています。これをどのように説明/証明するか。
私は、プログラムは高度に結合されており、多くの依存関係があり、単純なアプリをインストールしたい場合でも、多くの依存関係を考慮する必要があります(アプリケーションマネージャでわかるように)。一部の依存プログラムが中断される可能性があるため、プログラムを更新してください。実際、スタンドアロンソフトウェアは、他のオペレーティングシステムと比較して美しいLinuxの世界ではまれです。
答え1
全体として、代替案はより多くの努力をし、より少ないものを得ることであるので、これは意味があります。
ほとんどすべてのコンピューティングシステム(おそらくすべてのシステム、期間)はレイヤーで構築されています。すべてのプラットフォームはその下にあるコンテンツについて仮定します。ls
C標準ライブラリがあるとします。コアがあると推定されます。コンピューティングハードウェアがあると想定されます。安定した電圧などがあるとします。
次の仮定を行うことで、コードをより速く書くことができます。私は多くをすることができる。私はCライブラリ、zipライブラリ、または暗号ライブラリをバンドルすることに興味がありません。他の人がそうします。他の人がこれらのコンポーネントを改善またはアップグレードすることを決定した場合、私には確かに利益があります。このコードを共有する他のすべてのプログラムでも同様です。一貫したシステムでは、より速く、よりきれいで、より小さく、より良いです。
しかし、ご存知のように、より依存的です。暗号化が互換性のない方法でアップグレードされると、競合が発生し、パッケージ管理が困難になります。パッケージ管理を困難にする依存関係の種類を実際に分離するには、コンポーネントが依存関係をインライン化する必要があります。以下にさらにスタックを含める必要があります。そしてこれがまさに問題の核心です。依存性の低いプログラムを作成するには、より多くを理解するビルドシステムが必要です。。これは開発者が時間を過ごしたいと思ったり過ごしたりする場所ではありません。
あなたは現在の問題を「極端な組み合わせ」と表現します。人々はすべてをスタンドアロンにしようとしました。スターリー、すべてのバイナリを静的にリンクされたままにするように設計されたLinuxディストリビューションです。しかし、極端な分離は同じ効果を持つことができます。つまり、各プログラムに仮想マシンがあると想像してみてください。
私たちの業界の驚くべき成長は、主に過去を素早く基盤に構築する能力に起因しています。私たちは皆、文字通り、比喩的に、巨人の肩の上に立っています。おそらく将来、私たちは巨人の鍵を育てるための最初のステップとして巨人を食べることができます。しかし、現在としてはおおよその妥協が正しいようです。引き続き登り、私たちの下の巨人が仲良くなるようにしましょう。
答え2
カップリングは強いですか?実際、「一つのことをうまくやろう」という原則やパイプラインなどを使って動作するアプリケーションを構築することは、緩い結合を見せてくれると思います。たとえば、ps axf | grep vimを実行すると、psとgrepは非常に緩く結合されます。
答え3
Unix および Unix シリーズのオペレーティングシステムには「極端な組み合わせ」はありません。
極端なデカップリング(つまり独立したソフトウェア)は、すべてがCLIにあったUnixの初期には標準でした。
注目に値する唯一の結合コードは、シェルスクリプト自体です。これは、シェルスクリプトを使用可能にするには、呼び出すコマンドが必要なためです。これらのコマンドのほとんどは基本インストールの一部であるため、問題になりません。
大規模なライブラリ(グラフィック環境、X11、ウィジェットツールキットなど)を導入すると、単一の実行可能ファイルに必要なすべてのライブラリを含めることが、ストレージスペース(ディスクスペースが薄いときに実行可能ファイルが大きくなる)とメモリ使用量(同じコードがたくさんあります)繰り返し、RAMが不足している場合)。その後、これらの制限を克服するために共有オブジェクトが導入されました。
今、私たちは通常、必要なライブラリと同様のファイルがアプリケーションの依存関係ツリーをかなり複雑にする可能性がある状況に直面しています。開発者がコアアプリケーションに集中し、既存のアプリケーションに残りのアプリケーションを使用できるようにすることです。つまり、車輪を再発明しないでください。
新しいバージョンが以前のバージョンとの互換性を破り、名前の競合(同じコンピュータに一緒にインストールされたソフトウェアを除く)が原因で発生する問題を除いて、これは大きな問題を引き起こしません。良い設計と標準を使用すると、両方の問題を回避できます。