it-swarm-tr.com

C ++ 'da ad alanlarını kullanmak için en iyi uygulamalar

Birkaç ay önce Bob Amca'nın Temiz Kod okudum ve kod yazma şeklimde derin bir etkisi oldu. Her programcının bilmesi gereken şeyleri tekrarlıyor gibi görünse bile, hepsini bir araya getirmek ve uygulamaya koymak çok daha temiz bir kodla sonuçlanır. Özellikle, büyük işlevleri birçok küçük işleve ayırmayı ve büyük sınıfları inanılmaz derecede faydalı olmak için birçok küçük sınıfa ayırmayı buldum.

Şimdi soru için. Kitabın örnekleri Java'da, son birkaç yıldır C++ ile çalışıyorum. Temiz Kod içindeki fikirler Java'da bulunmayan ad alanlarının kullanımına nasıl uzanır? (Evet, Java paketleri hakkında biliyorum, ama gerçekten aynı değil.)

Her biri açıkça tanımlanmış bir sorumluluğu olan birçok küçük varlık yaratma fikrini isim alanlarına uygulamak mantıklı mı? İlişkili sınıflardan oluşan küçük bir grup her zaman bir ad alanına sarılmalı mıdır? Bu, çok sayıda küçük sınıfa sahip olmanın karmaşıklığını yönetmenin yolu mu yoksa çok sayıda ad alanını yönetmenin maliyeti yasaklayıcı mıdır?

Düzenleme: Sorum bu Paket İlkeleri hakkında Wikipedia girişi yanıtlanır.

39
Dima

( Temiz Kod okumadım ve fazla Java bilmiyorum.)

Her biri açıkça tanımlanmış bir sorumluluğu olan birçok küçük varlık yaratma fikrini isim alanlarına uygulamak mantıklı mı?

Evet, tıpkı birden çok sınıfa ve birden çok işleve yeniden düzenleme ile olduğu gibi.

İlişkili sınıflardan oluşan küçük bir grup her zaman bir ad alanına sarılmalı mıdır?

Aslında cevap vermeden: evet, en azından bir üst düzey ad alanı kullanmalısınız. Bu proje, organizasyon veya istediğiniz her şeye dayalı olabilir, ancak az sayıda global isim kullanmak isim çatışmalarını azaltır. Altındaki diğer her şeyi gruplamak için tek bir ad alanı yalnızca bir global ad verir. (Harici "C" işlevleri hariç, ancak bu C birlikte çalışabilirliğinden kaynaklanır ve yalnızca diğer harici "C" işlevlerini etkiler.)

İlgili sınıfların küçük bir grubu onlara adanmış mı? Muhtemelen bir ad alanına sarılmalıdır. Özellikle kendinizi bu sınıflarda ortak bir önek kullanarak bulursanız - FrobberThing, FrobberThang, FrobberDoohickey - bir ad alanı düşünmelisiniz - frobber :: Şey vb. Bu, daha büyük bir projenin parçasıysa, kök ad alanınızın veya başka bir ad alanının altında olacaktır.

Bu, çok sayıda küçük sınıfa sahip olmanın karmaşıklığını yönetmenin yolu mu yoksa çok sayıda ad alanını yönetmenin maliyeti yasaklayıcı mıdır?

Yukarıdaki ön ekli isimlerden örnek alındığında frobber :: Thing'i FrobberThing'den yönetmek zor değildir. Belgeler ve kod tamamlama gibi bazı araçlarla daha da kolay olabilir. ADL ile bir fark var, ancak bu sizin lehinize çalışabilir: ilişkili ad alanlarındaki daha az ad ADL'nin anlaşılmasını kolaylaştırır ve belirli adları bir ad alanına veya diğerine enjekte etmek için bildirimleri kullanarak koyabilirsiniz.

Ad alanı takma adları, belirli bir bağlamda daha uzun bir ad alanı için daha kısa bir ad kullanmanıza olanak tanır ve bu da daha kolay kullanıma izin verir:

void f() {
  namespace CWVLN = Company_with_very_long_name;  // Example from the standard.
  // In this scope, use CWVLN::name instead of Company_with_very_long_name::name.
  namespace fs = boost::filesystem;  // Commonly used.
}

Çeşitli kütüphaneler için tek bir kök ad alanı, boost ve ardından birçok alt ad alanı (boost :: asio, boost :: io, boost :: dosya sistemi, boost :: tuples, vb.) Olan Boost'u düşünün. Bazı adlar kök ad alanına "yükseltilir" :

Tüm tanımlar namespace :: boost :: tuples'dadır, ancak en yaygın adlar bildirimler kullanılarak namespace :: boost'a kaldırılır. Bu isimler: Tuple, make_Tuple, tie and get. Ayrıca, ref ve cref doğrudan :: boost ad alanı altında tanımlanır.

"Gerçek" modüllere sahip dillerden en büyük fark, daha düz bir yapı kullanmanın ne kadar yaygın olduğudur, bu daha çok olur, çünkü iç içe isimleri tanımlamak için fazladan özel bir çaba göstermedikçe bu şekilde çalışır.

23
Fred Nurk

Tüm kodlarınız için bir ana ad alanınız olmalıdır. Bu, onu ad alanlarıyla ilgili harici koddan ayırır.

Ana ad alanınızda, boyut ve karmaşıklığa bağlı olarak alt ad alanlarını açabilirsiniz. Burada isimler açıkça bir bağlam içinde bir şey ifade eder ve aynı isimler farklı bir bağlam içinde kullanılabilir.

Özellikle, bir bağlam içinde belirli bir şey anlamına gelen FileInfo gibi genel bir sondaj isminiz varsa, bunu bir ad alanına koyun.

Bir sınıf genişletilebilir olmasa da, üstbilgisini değiştirmeden sınıfa yeni bildirimler ekleyemeseniz de, bunun için bir sınıf da kullanabilirsiniz.

9
CashCow

Ad alanları bir Modül konsepti değildir, bu yüzden onları yalnızca ad çakışmalarının olabileceği yerlerde kullanırım.

3
Brainlag

Derin ad alanlarını severim (genellikle üç seviye anlamına gelir).

  • Şirket ismim var.
  • uygulama/Util/lib/etc
  • Proje Adı/veya Uygun Paket

Duruma bağlı olarak bir seviye daha alabilirim

  • ayrıntılar (Platforma özgü uygulama ayrıntıları)
  • (henüz genel yardımcı programa taşınmamış yardımcı program nesnesi).
  • neye ihtiyacım olursa.
1
Martin York

Java'nın ad alanları vardır, bunlar gerçekten böyle adlandırılmaz. İçinde javax.swing.*javax bir ad alanı ve swing bir alt ad alanı. Java paketleri hakkında ne yazdığını bilmek için kitabı okumadım, ancak aynı ilkeler hemen hemen herhangi bir dildeki ad alanlarına doğrudan uygulanacaktır.

İyi bir sezgisel tarama, sınıflar için aynı öneki tekrar tekrar yazmak istediğinizi bulduğunuzda bir ad alanı kullanmanızdır. Örneğin, son zamanlarda OmciAttribute, OmciAlarm, OmciMe, vb. Adlı bazı sınıflar yazdım ve Omci'yi kendi ad alanına ayırmam gerektiğini fark ettim.

1
Karl Bielefeldt