2

私が働いてきたすべての企業で、.netライブラリを拡張および拡張するだけのライブラリのコアセットを擁護することになりました。通常、私は会社名で始まる名前空間を持っていますが、サブ名前空間は名前空間の名前空間を反映していSystemます。

Foo.IO;
Foo.Web

私が計画しているのは、これをさらに一歩進めて、会社の名前空間をシステムの名前空間に置き換えることです。これにより、usingステートメントが1つだけ必要になり、コアライブラリがさらに強化されます。

namespace System.IO
{
    public static class StreamExtensions
    {
        ...
    }
}

実際の質問

これが可能であることはわかっています。Microsoftは独自のライブラリでそれを行っており、他のサードパーティのライブラリでもそれを行っていますが、私が知りたいのは、クラスなど、これを行うことの長期的な影響は何かということです。 .netの新しいバージョンでの名前の競合？誰かがこれを行い、アセンブリ参照を追加できるという単純さを壊した複雑さを処理しなければならなかったことがありますか？

アップデート

残念ながら、これはおそらくプログラマーに属する、これを行うべきかどうかについての議論になっています。卑猥にこれを尋ねる別のSO質問がありますが、それは質問のポイントではありませんでした。

コンパイルエラーや奇妙な動作を引き起こすシナリオがさらに先に発生するかどうかを知りたいと思いました。出てきた唯一の2つの議論はです。

  1. Microsoftは、ライブラリ内の拡張メソッドのシグネチャに一致するメソッドをオブジェクトに追加しますが、オブジェクトへの実装が優先されるため、拡張メソッドが存在する名前空間に違いがないため、これはミュートポイントです。

  2. 他の誰かがサードパーティのライブラリで同じことをしていて、名前が衝突しています。これはより可能性が高く、サードパーティのライブラリが他のライブラリをアセンブリにILMergeする場合にすでに対処する必要があります。

明確にするために、これはスタンドアロンライブラリであり、社内で使用するためのものであり、外部で利用できるようにするためのものではなく、Extensionメソッドを介して既存のシステムライブラリを拡張するためのものです。

4

3 に答える 3

2

私はこれをしないことをお勧めします。System名前空間は.NETFramework名前空間です。その名前空間からクラスをカスタマイズする場合は、コードで明示的にしてください。

つまり、カスタマイズされたクラスをカスタム名前空間の一部にするということです。

物事を台無しにしないでください。

于 2012-05-15T13:22:33.757 に答える
2

これは少し話題から外れているかもしれませんが、あなたが言及した代替アプローチを参照してください：

通常、名前空間は会社名で始まりますが、サブ名前空間はシステム名前空間の名前空間を反映しています。

私はそのアプローチでいくつかの問題を抱えていました。

私の会社名は Resolv です。そのため、私が書いたものの多くは、Resolv.<ProjectName> の形式で名前空間に入ります (残りは <ClientName>.<ProjectName> になります)。

Resolv.System という名前空間で、拡張メソッド、静的クラスなどのライブラリの構築を開始しました。

ただし、System で始まる「完全修飾」型名 ( var myVar = new System.Collections.List<int>(); など) を使用すると、名前空間の解決の問題が発生します。

その特定のケースでは完全修飾名を使用することはありませんが、参照している型がコード ファイル全体でその名前空間からの唯一の型である場合は、ときどき使用します (その場合、a の追加usingは保証されません) 。 - または、(using ステートメントを使用して) インポートされた 2 つの名前空間に競合する型名が含まれている場合。自動化されたコード生成ツール (resharper など) は、適切なusingステートメントがない場合に、この種の参照を追加することがよくあります。

Resolv 内の任意の名前空間(Resolv.MyInternalProject など) 内のコードに取り組んでいて、完全修飾名であるべきものを入力すると、Resolv.System 名前空間が原因で混乱が生じます。コンパイラは現在の名前空間に戻り、Resolv に到達してから Resolv.System を見つけます。これは、たとえばnew System.Collections.List<int>()、存在しないクラスを使用しようとすることを意味しますResolv.System.Collections.List<int>()。

もちろん、フォームを使用してそれを回避することはできますが、それはvar myVar = new global::System.Collections.List<int>()醜く、一種の苦痛です)。

代わりに、拡張機能の名前空間ツリーに「プロジェクト名」を含めることを選択したので、代わりResolv.SystemにResolv.Extensions.System. そこから、子の名前空間は System 名前空間をミラーリングします (例: Resolv.Extensions.System.IO)。そうすれば、System.xxx.xxxx の参照で拡張子を参照するか、特定のコード ファイルの .net 参照を参照するかをより適切に制御できます (また、必要なときにコード ファイルに追加する using ステートメントは 1 つだけです)。 「拡張機能をオンにする」)。

もちろん、Resolv.Extensions 名前空間内のコードで作業する場合、System.xxx.xxx 名前空間の混乱は依然としてありますが、日常的に問題になることはありません。:)

于 2012-10-13T01:47:41.563 に答える
0

私が計画しているのは、これをさらに一歩進めて、会社の名前空間をシステムの名前空間に置き換えて、1 つの using ステートメントだけで済み、コア ライブラリをより適切に拡張できるようにすることです。

これがコアライブラリを強化する方法がわかりません。Microsoft が同じメソッドをStringクラスに追加し、まったく異なることをするとどうなるでしょうか? これが、それらが独自の名前空間にある必要がある理由です。

これが可能であることがわかりました.Microsoftは独自のライブラリでそれを行い、他のサードパーティのライブラリでそれを見てきましたが、知りたいのは、もしあれば、クラスなどのこれを行うことの長期的な影響です. .net の以降のバージョンでの名前の競合?

長期的な影響は、作成した拡張メソッドと同じメソッドを Microsoft がクラスに追加した場合です。

誰かがこれを行い、アセンブリ参照を追加できるという単純さを破る複雑さを処理しなければなりませんでしたか?

参照の量を減らしたい理由がわかりません。これを行っても何も得られません。独自の名前空間とクラスにユーティリティ メソッドを含めることは有効な設計上の決定であり、人々はそれらが別個のものであり、Microsoft 名前空間の一部ではないと想定しています。

それは有効な声明ですが、その意味についての質問です。私を含む他の人々は、他の誰かの名前空間をいじることに対する「直感」の感覚のために、これを行うことを避けてきましたが、これが原因で行うなとは誰も言いませんでした. 具体的な事実上の理由がある場合は、ぜひお聞かせください。

これは、System 名前空間が Microsoft コードのみで満たされているという開発者の想定を意味します。

于 2012-05-15T13:43:31.967 に答える