Webページから多くの論理的な方法を抽象化し、「ヘルパー」クラスを作成しているようです。悲しいことに、これらのクラスはすべて同じように聞こえます。
ADHelper、（Active Directory）AuthenicationHelper、SharePointHelper
他の人はこの命名規則で多数のクラスを持っていますか？
13103 次
6 に答える
48
それはコードのにおいに該当すると思いますが、コードのにおいが必ずしも問題を引き起こすとは限らないことを覚えておいてください。それはあなたが調べて、それが大丈夫かどうかを判断する必要があるものです.
とは言っても、個人的には、そのような名前にはほとんど価値がなく、非常に一般的であるため、その型は関連のないユーティリティ メソッドのバケツになりやすいと思います。つまり、ヘルパー クラスはラージ クラスに変わる可能性があり、これは一般的なコードの匂いの 1 つです。
可能であれば、メソッドの機能をより詳細に説明する型名を見つけることをお勧めします。もちろん、これにより追加のヘルパー クラスが必要になる場合もありますが、それらの名前が役立つ限り、番号は気にしません。
少し前に、コード レビュー中に XmlHelper というクラスに出会いました。明らかに Xml に関係するメソッドがいくつかありました。ただし、型名からは、これらのメソッドに共通しているものは明確ではありませんでした (Xml 関連であることは別として)。一部のメソッドは Xml をフォーマットしており、他のメソッドは Xml を解析していることが判明しました。したがって、IMO クラスは、より具体的な名前を持つ 2 つ以上の部分に分割されているはずです。
于 2010-03-15T10:50:01.413 に答える
12
いつものように、それは文脈に依存します。
独自の APIを使用する場合、私FooHelperはそれを間違いなくコードのにおいだと考えFooますFoo。
ただし、既存の API (BCL の型など) を使用する場合、実装を変更することはできないため、拡張メソッドは元の API の欠点に対処する方法の 1 つになります。FooHelperと同様に、そのようなクラスに名前を付けることができますFooExtension。それは同じように臭いです（またはそうではありません）。
于 2010-03-15T10:37:21.963 に答える
8
クラスの実際の内容によって異なります。
ヘルパークラスに実際のビジネスロジック/ビジネスルールが大量にある場合は、「はい」と言います。
クラスが本当に他のエンタープライズアプリケーションで使用できる単なるヘルパーである場合（絶対的な意味で再利用します。コピーしてからカスタマイズするのではありません）、ヘルパーはコードの臭いではないと言えます。
于 2010-03-15T10:34:39.763 に答える
8
興味深い点です。単語が名前で「ボイラープレート」になる場合、それはおそらく少し気まぐれです-実際の匂いではないにしても. おそらく、「ヘルパー」フォルダーを使用して名前空間に表示できるようにすると、単語を使いすぎずに使用できますか?
Application.Helper.SharePoint
Application.Helper.Authentication
等々
于 2010-03-15T10:38:58.893 に答える
4
多くの場合、Helper拡張メソッドを含む静的クラスには で終わるクラスを使用します。私には臭くないようです。それらを静的でないクラスに入れることはできませんし、クラス自体は問題ではないので、ヘルパーは問題ないと思います。いずれにしても、そのようなクラスのユーザーにはクラス名が表示されません。
.NET Framework もこれを行います (たとえば、LogicalTreeHelper静的 (非拡張) メソッドがいくつかある WPF のクラスなど)。
ヘルパー クラスのコードを「実際の」クラス、つまりクラス階層に適合するオブジェクトにリファクタリングすると、コードが改善されるかどうか自問してください。コードはどこかにある必要があり、単純なヘルパー関数 (つまり「ヘルパー」) のように、コードが実際に属しているクラス/オブジェクトを特定できない場合でも問題ありません。
于 2010-03-15T10:39:25.623 に答える
-3
コードの匂いとは言いません。ASP.NET MVC では、これは非常に一般的です。
于 2010-03-15T10:31:57.497 に答える