15

3.days.from_nowRailsは、3 日先の日付を期待するように、戻り値のように Ruby にいくつかのコア拡張機能を導入しました。C# の拡張メソッドを使用して、同様のことができるようになりました。

static class Extensions
{
    public static TimeSpan Days(this int i)
    {
        return new TimeSpan(i, 0, 0, 0, 0);
    }

    public static DateTime FromNow(this TimeSpan ts)
    {
        return DateTime.Now.Add(ts);
    }
}

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(
            3.Days().FromNow()
        );
    }
}

またはどうですか：

static class Extensions
{
    public static IEnumerable<int> To(this int from, int to)
    {
        return Enumerable.Range(from, to - from + 1);
    }
}

class Program
{
    static void Main(string[] args)
    {
        foreach (var i in 10.To(20))
        {
            Console.WriteLine(i);
        }
    }
}

これは根本的に間違っているのでしょうか、それとも、Rails のようなフレームワークのように、それが良い考えである場合もありますか?

4

7 に答える 7

6

まず、私の腸の感覚：3.Minutes.from_now完全にクールに見えますが、拡張メソッドが優れている理由を示していません。これは私の一般的な見方も反映しています。かっこいいですが、本当に見逃したことはありません。

質問：3.Minutesタイムスパンですか、それとも角度ですか？

usingステートメントを介して参照される名前空間は、「通常」は型にのみ影響しますが、突然、3.Minutes意味を決定します。

したがって、最善は「彼らを逃がさない」ことです。
参照される可能性のある名前空間内のすべてのパブリック拡張メソッドは、最終的に「一種のグローバル」になり、それに関連するすべての潜在的な問題が発生します。それらをアセンブリの内部に保持するか、各ファイルに個別に追加される個別の名前空間に配置します。

于 2008-12-16T14:14:00.587 に答える
5

個人的には int.To が好きで、int.Days には賛否両論あり、TimeSpan.FromNow は嫌いです。

私は、疑似英語コードを記述できる「流暢な」インターフェースの流行のように見えるものを嫌いますが、それは、単独では困惑する可能性のある名前のメソッドを実装することによって行います。

たとえば、これは私にはよく読めません：

TimeSpan.FromSeconds(4).FromNow()

明らかに、それは主観的なものです。

于 2008-12-16T13:25:19.983 に答える
1

私はこの問題についてsizとleanconservativeに同意します。Railsにはそのようなものが組み込まれているので、それほど混乱することはありません。「days」メソッドと「fromnow」メソッドを作成する場合、コードにバグがないという保証はありません。また、コードに依存関係を追加しています。拡張メソッドを独自のファイルに入れる場合は、すべてのプロジェクトでそのファイルが必要です。プロジェクトでは、必要なときにいつでもそのプロジェクトを含める必要があります。

とはいえ、他のフレームワーク/世界に存在する本当に単純な拡張メソッド（Jeffによる「left」の使用法やthatismattによるdays.fromnow上記の使用法など）については、問題ないと思います。日付に精通している人は、「3.Days（）。FromNow（）」の意味を理解する必要があります。

于 2008-12-16T14:15:28.820 に答える
0

私は、少なくとも当分の間、スペクトルの保守的な側にいて、拡張メソッドに反対しています。私にとってそれほど重要ではないのは、単なる構文糖衣です。C# に不慣れなジュニア開発者にとっても悪夢になる可能性があると思います。拡張機能を自分のオブジェクトまたは静的メソッドにカプセル化したいと思います。

それらを使用する場合は、自分にとっては便利であるが、コードに触れる他の誰かを台無しにするほど過度に使用しないでください。:-)

于 2008-12-16T14:04:20.013 に答える
0

各言語には、言語がどうあるべきかについて独自の視点があります。Rails と Ruby は、それぞれ独自の非常に異なる意見に基づいて設計されています。PHP は、C(++/#) と同様に、明らかに異なる意見を持っています... Visual Basic もそうです (しかし、明らかに私たちはそれらのスタイルが好きではありません)。

バランスは、すべてを細かく制御するのとは対照的に、多くの読みやすい組み込み関数を備えています。何かをするたびにルックアップに行かなければならないほど多くの関数は必要ありません (そして肥大化したフレームワークにはパフォーマンスのオーバーヘッドが必要です) が、個人的には Rails が大好きです。開発に多くの時間を費やします。

ここで私が言いたいのは、言語を設計している場合、スタンスを取り、そこから進んで、あなた (またはターゲットの開発者) が最も頻繁に使用する機能を組み込むということです。

于 2008-12-16T14:07:30.537 に答える
0

私の個人的な好みは、今のところ控えめに使用し、Microsoft や他の大企業がどのように使用するかを待つことです。多くのコード、チュートリアル、書籍で 3.Days().FromNow() のようなコードが使用されているのを見始めると、それが頻繁に使用されます。少数の人しか使用しない場合、拡張機能の仕組みに精通している人が十分ではないため、コードの保守が非常に困難になるリスクがあります。

関連して、通常の for ループと foreach のパフォーマンスを比較するとどうなるでしょうか。2 番目の方法は、コンピューターに多くの余分な作業が必要になるように思えますが、私はこの概念に十分に精通しておらず、確実に知ることができません。

于 2008-12-16T14:35:22.527 に答える