2009-04-16 226 views
4

如果我在一個圖層上具有與另一圖層上的對象相同名稱的對象,最好是使用某個前綴更改對象名稱,還是使用新的命名空間並使用完全限定名稱引用它們?例如:命名約定和命名空間

namespace Project1.Data 
Object Person; 

namespace Project1.Model 
Object Person; 

Data.Person.Name=Person.Name; 

OR 

dbPerson.Name= Person.Name; 

回答

12

我會使用的命名空間和命名空間的別名,如:

在適當的命名空間定義你的類:

namespace Project1.Data 
{ 
    public class Person {...} 
} 
namespace Project1.Model 
{ 
    public class Person {...} 
} 

你在哪裏使用類,要麼使用完全限定的名稱,要麼爲名稱空間定義一個別名(尤其是在完整名稱空間很長的情況下使用):

using data = Project1.Data; 
using model = Project1.Model; 

data.Person p1 = new data.Person(); 
model.Person p2 = new model.Person(); 
//... 
p1.Name = p2.Name; 
+4

有一點需要注意,(僅僅添加到您的答案中)不要僅爲一個別名使用別名。使用別名'並始終使用別名引用它們。不要讓其中的一個陷入默認狀態,因爲這會造成混亂。 – DevinB 2009-04-16 20:34:27

2

這取決於您指的是重複名稱的頻率。

如果您在一個文件中多次使用它,請使用第一種方法。

如果您只使用一次或兩次,則寫出完全限定的名稱,以便其他人不必在您的文件頂部四處尋找來找出您所指的對象。

1

這實際上取決於你要求他們每個人的頻率。通常,我使用最常用的類型的縮寫版本,並且使用較不常用的類型的較長名稱。我最終會說,如果你最終在同一個文件中有很多用法,那麼你應該使用命名空間別名,但對我來說,這是最後的手段,只有在代碼膨脹到很難關注正在發生的事情。

1

自己也有同樣的想法。我認爲挑選班級的名字是一個壞主意。例如,我有一個數據訪問層和一個業務層。兩者都與用戶打交道。所以,我有...

Project1.Business.User Project1.DataAccess.User

試圖想爲類新發明的名稱是在浪費時間,將可能意味着很少類名字真怪含義。命名類已經足夠讓人頭疼了。

我同意McWafflestix「我使用最常用的類型的縮短版本,並使用較少使用的類型的較長名稱」。

1

很簡單。聽一次.NET框架的指導方針實際上有所幫助(儘管本書中的大量內容僅僅是Java風格的元素,但在雷德蒙德仙境中又是如此)。

您應該避免交叉或項目內類似的類型名稱/庫混合名稱空間即。在通用領域和模型之間進行混合(即使在C++中,它也非常嚴格而且功能強大,它在編譯器,解析和枚舉式編譯器崩潰和問題方面也具有化身)。因此,即使是完全符合條件的所有時間也不是沒有錯誤的(並且btw別名和'using'極其有限,最多隻會導致輕微的重複,並且證明C#在泛型編程方面的弱點等)。

以我的經驗,數據域類型是一個更合適的名稱的主要目標,從而爲名稱的重構是:

一)便宜(如豐富的AST,但簡單ADT-S支持的處理等在C#中,在IDE中右鍵單擊,並根據類型挑戰的動態Ruby粉絲/支持者感覺功能強大)

[也可以理解爲:4.0動態特性羊會責怪每個人但不考慮名稱空間或功能JS,C -with模板(不帶C類),或類似的]

b)更好地傳達語義,即。意圖(即管道+支持建立你自己的處理)

c)通常是原始的,但類型的性質或消息(鍵入不OO;即OO風格的批評,如上述書本身直接破壞了介紹升降機所有「模型」來引用土地)

d)和「混疊」變爲跨域使用一個有用的僞影(其實際上是可能的,並且相當2020樣..即值類型編程)

實際上沒有規則,但要小心,當最不可預料的情況下,你會看到名稱空間在開發中的混合。這意味着管理型開發人員只有一件事:混淆。加上稍微不嚴重,編譯時和IntelliNonsense錯誤,當然..

在所有語言的棘手問題,所以這是你的設計/命名問題。即使工具供應商可以搞砸機器解析..說輸出基於過時瀏覽信息的增強型流行IDE;然後再一次,其他人對託管語言很好。

不是我反對複製名稱,有混淆雙+互操作+表示等其他模型的情況下(他們是艱難的,但必要的),其中同名的其他模型更容易閱讀;即。重複是雙重用途的必要條件..但這是C#不友好或鼓勵(低成本的慣用語),(贊成開銷)。