3

EiffelBuild は、Eiffel 専用の ISE GUI 構築グラフィカル ツールです。

試してみると、とても使いやすいと思いますが、大規模なプロジェクトでこのようなツールを使用するのは少し心配です。GUI 構築ツールの使用は制限される可能性があります。

Eiffel の継承により、コンポーネントの作成が非常に簡単になるため、長期的には、標準のものを使用するグラフィカル オブジェクトの独自の特殊バージョンを使用する方がよい場合があります。

大規模なプロジェクトでの使用を避けることを正当化する EiffelBuild の制限を認識していますか?

4

2 に答える 2

3

私は EiffelBuild の使用をプロトタイピングに制限します。これは素晴らしいツールですが、長い目で見れば、EiffelBuild プロジェクトの管理はますます複雑になります (これはほとんどのデザイナーに当てはまります)。

  • estudio の新しいバージョンは 6 か月ごとにリリースされるため、EiffelBuild プロジェクトを 1 つのバージョンから別のバージョンへと期待どおりに機能させ続けることは負担になります。これで、すべての Eiffel コードが同じ課題の対象になりますが、EiffelBuild のプロジェクトでは、言語と EiffelBuild の両方の変更に対処する必要があります (時には両方同時に...)
  • バージョン N+1 と N に互換性がない場合は、EiffelBuild プロジェクトのブランチを作成して、両方のバージョンをサポートする必要があります (移行期間中のみ)。
  • 複数の EiffelBuild プロジェクトを統合するのは難しい場合があります
  • 一部のグラフィカル コンポーネントは、EiffelBuild で再利用するのが難しい場合があります。たとえば、特殊なチャート コンポーネント (クラスのセットなど) などです。特に、そのコンポーネントが EiffelBuild プロジェクト自体ではない場合は特にそうです。
  • ある EiffelBuild アプリケーションで作成されたパーツを別のアプリケーションで再利用するのは難しいことがわかりましたが、かなり適切に設計されたコンポーネントを使用すれば、それほど問題になりません。

お役に立てれば。

于 2009-09-19T05:59:06.253 に答える
1

試してみると、とても使いやすいと思いますが、大規模なプロジェクトでこのようなツールを使用するのは少し心配です。GUI 構築ツールの使用は制限される可能性があります。

これはどのように「制限的」ですか？また、プロジェクトの規模はどのように影響しますか?

それがコード ジェネレーターであり、そこから出てくるコードを完全には理解していないという意味であれば、私は完全に同意します。コード生成が機能するのは、コードを手書きで書いている場合のみであり、ジェネレーターは単調な作業を省くことでリフトを与えてくれます。その場合、生成されたコードを変更して維持することに完全に自信を持っています。

Eiffel の継承により、コンポーネントの作成が非常に簡単になるため、長期的には、標準のものを使用するグラフィカル オブジェクトの独自の特殊バージョンを使用する方がよい場合があります。

追加する専門分野は何ですか? これは、大規模なクラス階層を永続的に作成、デバッグ、および維持することを意味するため、これを行うことについて慎重に検討します。この手順を実行する前に、専門化が必要であり、コストに見合うだけの価値があり、他の方法では取得できないことを完全に確認してください。決定する前に、コストを定量化する誠実な努力をしてください。

ライブラリ GUI クラスを使用して十分なハンド コーディングを行ったら、独自のコード ジェネレータを作成することに投票します。それは持続可能な解決策です、IMO。

アップデート：

私は大学院プログラムで Eiffel を学び、90 年代半ばにそれが利用可能な最高のオブジェクト指向言語であると判断しました。当時、C++ は卓越したものでしたが、複雑であると考えられていました。Java は Sun の研究室から抜け出すことができず、C# は Anders の目にはちらつきさえありませんでした。この施設の教員は、契約による設計と、それが意味する学問的厳格さの極致に夢中になりました。

Meyers の「Object Oriented Software Contruction」を読みました。第 1 版では DbC が紹介され、マイヤーズはオブジェクト指向の世界のスターになりました。私の意見では、第 2 版は彼の上昇に終止符を打った肥大化したものでした。

正直なところ、雇用主のためにこの大規模なシステムを作成している場合は、Eiffel をやめて、彼らとあなたのために、より主流の言語に切り替えることをお勧めします。Windows プラットフォームを使用している場合は、C# が適しています。異機種混合環境を使用している場合、または Microsoft スタックを購入する余裕がない場合は、Java を使用してください。

SO には、Eiffel に関する 4 つのタグ付きの質問がすべて含まれています。ボリュームが何かを物語っていると思います。人気が常に品質の最良の指標であるとは限らないというのは正しいかもしれません。ベータ版は VHS よりも優れた技術的解決策だったと言われていますが、実際のところ、ベータ版は市場で失われ、今日ではどこにも見つかりません。エッフェルと同じ。私があなただったら、私はそれを落とします。

更新 2:

非常に良かったです。最初の投稿からは、他の言語での経験がどのようなものであったかわかりませんでした。

「高い品質への期待」は、Eiffel が他の言語では真似できない方法で言語レベルで品質をサポートすると信じていることを意味します。私はそれに同意しません。コードの品質は、言語そのものよりも、開発者のスキルと実践に関係しています。

契約による設計は完全に売られすぎです、IMO。パフォーマンスに影響を与えるため、本番環境ではオフになっていることが多いと読んだことがあります。もしそうなら、Eiffel が品質にどのように貢献すると思いますか?

あなたがこのアプリケーションを作成しているクライアントが、Eiffel を使用するという決定がもたらす結果を完全に理解していることを確認したいと思います: それを維持する開発者の限られたプール、死んだ言語の使用によって疎外されたスタッフなど.主観的な希望で過剰販売しないように注意してください。

于 2009-09-12T16:32:56.480 に答える