Javaが開発されたとき、設計者はUNIXおよびC指向のツールチェーンで確立された従来の常識の異常な量を破棄することを選択しました.1つ(そして私の見解では)最も主要な例として、彼らは選択しましたヘッダーファイルとMakefileの慣習を破棄し、代わりにモノリシックで依存関係を認識するコンパイラを構築しようとしました。その後、このプロセスの(明らかな?)欠陥を部分的に修正し、効果的に再構築するためにant
が開発されました。 makefileロジックを実装しました。
古いスタイルのメイクに憤慨しているわけではなく、#include
船外に出る。ただし、それらの使用法はJava world with ant
で再発明され、各クラスをインターフェイスクラスと実装クラスに分割しました。これはヘッダーファイル/ソースファイルのパターンに非常に近いものです。 。Javaは既存のツールとパターン、およびそれらの目的を知っていたと確信しているので、最初にそれらを廃止し、次にすべてを最初から再実装するという決定は、言語設計ではそれが私を驚かせます。より安価な方法が利用可能でしたが(ソースファイルの解析やヘッダーファイルの自動生成など、C構文を少し削除した後はかなり簡単でした)、そうではありませんでした。取られた、そして私は理由について知りたいです。
同様のフォークが他のほとんどの場所で実行されましたが、かなりの開発コストと分割されたコミュニティのかなりのコストがかかりました。今日、Javaの開発者とC++の開発者は、C/C++言語とJava言語)の実際の違いに不釣り合いに見える分割のために、コミュニケーションとコラボレーションに苦労することがよくあります。プロセスの背後にある基本的な動機を見ることができます(誰もがMakefile構文を嫌い、ヘッダーファイルを手動で変更します)が、それでも変更の大きさを理解することはできません。
このプロセスの動機と理由についての歴史的な言及はありますか?このフォークを運転した人々へのデザインドキュメントやインタビューはありますか?
実際には別の観点から見る必要があります。Javaでは、インターフェイスの形式でヘッダーファイルを作成できますが、実際にはC/C++でヘッダーファイルが必要です。
その後、antは、このプロセスの(明らかな?)欠陥を部分的に修正するために開発され、makefileロジックを効果的に再実装しました。
物事を成し遂げるためのツールとしてantを見てください。 Javaアプリケーションを構築するために必要なツールの代わりに、アプリケーションをビルド、デプロイ、または公開します。また、Javaはantにバインドされていません。同様に、ちなみに、C/C++はmakefileにバインドされていません(事実上の業界標準ですが)。Javaの世界では、他のビルドツール、つまり への顕著な動きがあります。 )Maven および Gradle 。これらは、例外による依存関係の管理や構成などの追加機能を提供します。
Makefileからantへのステップは、タスクを実行するための優れたサポートによって推進されてきたと思います。さらに、コンパイラや開発者がヘッダーファイルを必要としないのに、なぜヘッダーファイルが必要なのですか?
これはおそらくあなたのデザインドキュメントやインタビューの要求に答えることはできませんが、うまくいけば、これが自然な発展であった理由のいくつかのアイデアをあなたに与えるでしょう。
C(C++およびObjectiveC)を含む言語以外の言語は、ヘッダーを使用しません。 Cより前の言語も新しい言語もありません。
これは、ヘッダーが非常に重要な「Do n't Repeat Yourself」の原則に違反しているためです。すべての情報は実際にはソースファイルにあるため、コンパイラは情報自体を生成する必要があります。
実際、ヘッダーはおそらくCにとっても後付けです。 Cの初期バージョンでは、プロトタイプなしで関数を呼び出すだけでしたが、Cは、そのような場合に引数をマーシャリングする方法に関するルールを引き続き実行します(そして、それらは可変個引数関数にとって依然として重要です)。プロトタイプが追加され、プリプロセッサが悪用されてそれらを引き込み、それがスタックしました。オペレーティングシステムと標準ライブラリで低レベルの作業を行うときに便利な、コンパイラで汚いトリックを再生できることが判明したことも一因です。これらのトリックは、一般的に高水準プログラミングには役立ちません。
ヘッダーがない場合は、次の3つのオプションがあります。
Javaは最後のものを選びました。 C#は、他の多くの言語と同様に機能しました。