Whats は、一般/共通機能を処理するためのいくつかの静的メソッドを持つ私の静的クラスの理想的なクラス名です。これには、バックアップの取得、最近の項目の保存などがあります.. (Infact Misc items ) in C#. クラス名のサフィックスとして Manager を使用したいと思います (例: SaleManager (販売関連の機能を処理するため)、ContatManager (連絡関連の機能を処理するため))
10 に答える
RefactorMeManager。
これらのタイプの操作を実行する.NETFrameworkクラスを次に示します。
- System.Environment
- System.Math
- System.IO.File
- System.IO.Directory
- System.IO.Path
- System.Runtime.InteropServices.Marshal
ご覧のとおり、ルーチンはトピックごとにクラスにグループ化されており、どのクラスにも「ヘルパー」または「ユーティリティ」が追加されていません。これらのタイプのいくつかを実行するために私が作成したいくつかのクラスは次のとおりです。
- SymbolicMath(Mathクラスに似ていますが、シンボリック数学式を操作するため)
- BigIntegerMath(System.Numerics.BigIntegerタイプを使用した大整数演算のライブラリ-素数性の証明、因数分解、およびその他のいくつかのこと)
「効用」は物議を醸しているが、「数学」は物議を醸していないことがわかった。したがって、名前は静的クラスのメソッドの全体的な機能を示唆しているように思われます。
If you have a Utility (or UtilityManager) class that has lots and lots of static methods, that is indeed an anti-pattern and should be refactored pronto.
However, there are the things that are just that - utilities, and one should not refrain from putting them in a separate Utilities class (my personal favourite). Yes, that opens the door for all sorts of ugly scenarios, and one has to hold the reins, or anything and everything will end up there, and yes, there is a need to "promote" methods to their own class (usually XXXHelper) if the need arises, but, nonetheless, I find the Utilities class a helpful construct, and not an anti-pattern by itself. Patterns are a recommendation after all, they are not a religion :)
Manager as a suffix for that kind of a class is confusing, because the class does not in fact manage anything.
万歳internal static class Utils
。
私の一般的な感覚は、そのような一般的なクラスを持つべきではないということです。特に電子メールは、SendEmail()メソッド以上のものに拡張される可能性が非常に高く、率直に言っnew Email({to, subject, body}).Send()
て、より多くのOOの意味があります。
Tools
Utils
Extensions (そこに拡張メソッドだけを入れる場合 (C#))
UtilityManager ..?
そのようなことをしないのには非常に正当な理由があります。アンチパターンと見なされます。
静的クラスの場合でも(ところで、私はXxxHelperサフィックスが好きです)、「関心の分離」というパラダイムに固執し、1つのクラスに異なるユーティリティを混在させません。