11

ここ数か月、私は Java から Groovy に移行してきましたが、Java から Groovy への移行を行ってきました。コードの削減、クロージャー、ビルダー、最終的に Grails のようなフレームワークを可能にする MOP、テストを作成する際のモックの容易さなど、多くの利点を評価できます。 .

しかし、私のコードは十分にグルーヴィーではないと同僚から「非難」されています。つまり、私はまだパラメーターとフィールドの型を宣言しており、ダックタイピングなどの代わりに継承とポリモーフィズムを使用する傾向があります。これらの状況では、動的対静的だけでなく、動的対オブジェクト指向パラダイムでもあるようです。一種のジレンマ。そのような場合、私はまだ OO を好む傾向があります。OO パラダイムは、コード構成を抽象化し、特定の実世界の概念に関連付けることができるという基本的な前提に大きな価値があると感じています。

だから、ここに私が助けを必要とする特定の質問があります：

  1. パラメータやフィールドなどの型を宣言する必要がありますか?

  2. 単純なメソッドで行う場合、コードのブロックをクロージャーとして宣言する必要がありますか?

  3. ポリモーフィック ダイナミック ディスパッチの代わりにダック タイピングを使用する必要がある場合。たとえば、groovy では、animal."$action"() または def animal; を実行できます。animal.action() 、代わりに Animal animal = new Dog(); animal.action()。Open-Closed 原則のコンテキストで最初の問題を見ることができますが、オブジェクト指向スタイルのポリモーフィズムを好む他の理由はありますか?

  4. groovy でインターフェイスを使用する必要があるのはいつですか?

書ききれなかった同様のジレンマが他にもあると確信しています。また、これらの質問は groovy だけでなく、他の動的言語にも当てはまると思います。あなたの意見は何ですか？

4

6 に答える 6

6

これは必ずしも一般的な意見ではありませんが、コードが明確で明確であればあるほど良いと思います。

何が起こっているのかを推測させてしまうような構成は嫌いです...

私はRubyで1年間働いていましたが、まったく気に入らなかった。優れた場所がないと言っているのではなく、物事をクリーンで明確に保つのが本当に好きで、Rubyがそれを目標としているとは感じていなかったと言っているだけです。

私が確かに理解したことの1つは、入力する量が全体的な開発速度と同じではないということです。繰り返しコードが多い複雑なコードベースでは開発が非常に遅くなるのは事実ですが、重複を排除せずに入力する内容を単純に減らすことは無意味であり、より長く、より明確で、より明示的なコードを入力する方が一般的に高速になります（プロジェクトの長さ）簡潔で形式的でない言語で書かれた同じコードよりも。

タイピングが開発速度と関係がないと思われる場合は、次にプロジェクトをリリースするときに、コードの行数を数え、費やした工数（デバッグとテストを含む）で割ります。つまり、1日に入力されたコードの量です。結果は非常に少数であることがわかります。実際、コードを入力することは、ソフトウェアプロジェクトのごく一部です。

于 2009-12-09T21:44:21.027 に答える
2

Groovy では、何かを実行する最も単純な方法を優先し、状況が必要な場合にのみ、Groovy 機能に頼るべきだと思います。(マクロを書いたり、Clojure でマルチメソッドを作成したりするときのように、これらのツールに頻繁にアクセスする場合は、自問する必要があります。) あなたの慎重なアプローチは私には問題ないように思えます。 . （初めてではないでしょう。）

Groovy のような柔軟な言語を持つことの良い点は、必要なときに頼れる強力な代替手段があることを知っているので、慎重なアプローチから始めることができることです。ご存じのように、「機能する可能性のある最も単純なこと」です。

より具体的には、インターフェースよりもダックタイピングを好み、パラメーターの型を気にしないことは良いことのように思えます。テストにモックを提供するのがずっと簡単になるかもしれません。

于 2009-12-09T21:15:09.980 に答える
1

それは人々が快適であることに帰着します。私はJavaに慣れているので、型のデクレレーションとメソッド呼び出しを使用するのが好きです。私が作成するコードは、動的計画法の経験があまりない人が管理する必要があるため、高度なGroovy機能を使用する正当な理由がない限り、通常のJavaコードに近い状態に保ちます。あなたのグループは、Groovyの特定の機能が一般的にいつ使用されるべきかを説明しようとするコーディング標準を作成する必要があるようです。

于 2009-12-09T21:40:24.867 に答える
1

.1. パラメータやフィールドなどの型を宣言する必要がありますか?

私は、パブリック API の一部として使用されるクラス、他の開発者が大量に使用するもの、または IntelliJ からの追加のオートコンプリート ヘルプが必要なクラスで型を宣言する傾向があります。そうでなければ、私は物事を「定義」します。

.2. 単純なメソッドで行う場合、コードのブロックをクロージャーとして宣言する必要がありますか?

変数として渡す予定がない限り、メソッドを使用します。「foo.&bar」メソッド逆参照演算子がありますが、ほとんどの開発者はこれを知らず、遭遇すると混乱します。また、説明目的で独自のメソッドに入れるのではなく、より大きなメソッドに残すことが明らかな小さなコードの場合にも、クロージャーを使用します。

.3. ポリモーフィック ダイナミック ディスパッチの代わりにダック タイピングを使用する必要がある場合。たとえば、groovy では、animal."$action"() または def animal; を実行できます。animal.action() 、代わりに Animal animal = new Dog(); animal.action()。Open-Closed 原則のコンテキストで最初の問題を見ることができますが、オブジェクト指向スタイルのポリモーフィズムを好む他の理由はありますか?

animal."$action"() フォームは、そのレベルの間接化が必要な場合にのみ使用します。これは、メソッド名がコード実行パスに基づいて変化するためです (ほとんどの場合、重いメタプログラミング中)。Animal animal = new Dog(); を使用します。オートコンプリートで IDE の助けが必要な場合、またはそのレベルのドキュメントがコードの明確化に役立ちます (そして、明白または制約となる可能性のある余分な冗長性によって損なわれることはありません)。

.4. groovy でインターフェイスを使用する必要があるのはいつですか?

私はめったにそれらを使用しません。これらは主に、パブリック API 呼び出しで想定されるフィールドのドキュメントとして使用するか、メタプログラミングの観点からクラスのセットを別のセットと区別するのに役立つマーカー インターフェイスとして使用することができます。それらは Java よりも groovy ではあまり役に立ちません。

于 2009-12-10T04:49:07.677 に答える
0

オブジェクト指向言語には 2 つの主要なタイプがあります。

C++ や Java などのSimula 67ファミリの言語は、静的に型指定された変数、コンパイラとリンカー、およびメソッド vtable を優先します。

Ruby などのSmalltalkファミリーの言語は、関数ポインター テーブルではなく、動的に型指定された変数、解釈、およびメッセージ パッシングを優先します。

どちらもオブジェクト指向ですが、オブジェクト指向の概念は大きく異なります。

于 2009-12-09T21:59:19.027 に答える
-1

はい

--

いいえ

この質問には本当の答えがないことを知っていますか?

于 2009-12-09T21:52:39.813 に答える