Sınıfta statik yöntemlere karşı ad alanı + işlevleri

Diyelim ki bir dizi ilgili fonksiyonum var ya da yazacağım. Diyelim ki matematikle ilgili. Örgütsel olarak:

1. Bu işlevleri yazın ve bunları MyMathad alanım içine koyun veMyMath::XYZ()
2. Adlı bir sınıf oluşturun MyMathve bu yöntemleri statik hale getirin ve benzer şekildeMyMath::XYZ()

Yazılımımı organize etmenin bir yolu olarak neden birini diğerinden seçeyim?

Varsayılan olarak, ad boşluklu işlevleri kullanın.

Sınıflar, ad alanlarının yerine nesnelerin oluşturulması içindir.

Nesneye Dayalı kodda

Scott Meyers, Etkili C ++ kitabı için "Üye olmayan arkadaş olmayan işlevleri üye işlevlerine tercih et" başlıklı makalenin tamamını yazdı. Herb Sutter'ın bir makalesinde bu prensibe çevrimiçi bir referans buldum:http://www.gotw.ca/gotw/084.htm

Bilmeniz gereken önemli olan şudur: C ++ işlevlerinde bir sınıfla aynı ad alanındaki işlevler o sınıfın arabirimine aittir (çünkü ADL işlev çağrılarını çözerken bu işlevleri arayacaktır).

Ad boşluklu işlevler, "arkadaş" olarak bildirilmedikçe, sınıfın iç bileşenlerine erişemezken, statik yöntemlere sahiptir.

Bu, örneğin, sınıfınızı korurken, sınıfınızın iç kısımlarını değiştirmeniz gerektiğinde, statik olanlar da dahil olmak üzere tüm yöntemlerinde yan etkileri aramanız gerekeceği anlamına gelir.

Eklenti I

Sınıf arayüzüne kod ekleme.

C # 'da, sınıfa erişiminiz olmasa bile bir sınıfa yöntem ekleyebilirsiniz. Ancak C ++ ile bu mümkün değildir.

Ancak, yine de C ++ 'da, birisinin sizin için yazdığı bir sınıfa bile, ad boşluklu bir işlev ekleyebilirsiniz.

Diğer taraftan, kodunuzu tasarlarken bu önemlidir, çünkü işlevlerinizi bir ad alanına koyarak kullanıcılarınıza sınıfın arayüzünü artırma / tamamlama yetkisi vereceksiniz.

Dahili II

Önceki noktanın bir yan etkisi, birden çok başlıkta statik yöntemler bildirmek imkansızdır. Her yöntem aynı sınıfta bildirilmelidir.

Ad alanları için, aynı ad alanındaki işlevler birden çok başlıkta bildirilebilir (neredeyse standart takas işlevi bunun en iyi örneğidir).

Uzantı III

Bir ad alanının temel serinliği, bazı kodlarda, "using" anahtar sözcüğünü kullanırsanız, bundan bahsetmekten kaçınabilmenizdir:

#include <string>
#include <vector>

// Etc.
{
   using namespace std ;
   // Now, everything from std is accessible without qualification
   string s ; // Ok
   vector v ; // Ok
}

string ss ; // COMPILATION ERROR
vector vv ; // COMPILATION ERROR

Ve hatta "kirliliği" bir sınıfla sınırlayabilirsiniz:

#include <string>
#include <vector>

{
   using std::string ;
   string s ; // Ok
   vector v ; // COMPILATION ERROR
}

string ss ; // COMPILATION ERROR
vector vv ; // COMPILATION ERROR

Bu "model", neredeyse standart takas deyiminin düzgün kullanımı için zorunludur.

Ve bu, sınıflardaki statik yöntemlerle yapmak imkansızdır.

Yani, C ++ ad alanlarının kendi semantikleri vardır.

Ancak, ad alanlarını kalıtıma benzer bir şekilde birleştirebileceğiniz için daha da ileri gider.

Örneğin, AAA işlevli bir ad alanı A, BBB işlevli bir ad alanı B varsa, bir ad alanı C bildirebilir ve anahtar kelimeyi kullanarak bu ad alanına AAA ve BBB getirebilirsiniz.

Sonuç

Ad alanları ad alanları içindir. Sınıflar sınıflar içindir.

C ++ her kavramın farklı olması için tasarlanmıştır ve farklı durumlarda farklı sorunlara bir çözüm olarak farklı şekilde kullanılır.

Ad alanlarına ihtiyacınız olduğunda sınıfları kullanmayın.

Ve sizin durumunuzda, ad alanlarına ihtiyacınız var.

Benimle aynı fikirde olmayan birçok insan var, ama ben böyle görüyorum:

Bir sınıf aslında belirli bir nesnenin tanımıdır. Statik yöntemler, o nesne tanımına yakından bağlı olan işlemleri tanımlamalıdır.

Sadece bir temel nesne veya bir tür nesnenin tanımı ile ilişkili olmayan bir grup ilgili fonksiyona sahip olacaksanız , o zaman sadece bir ad alanı ile gitmek söyleyebilirim. Sadece benim için, kavramsal olarak, bu çok daha mantıklı.

Örneğin, sizin durumunuzda kendinize, "MyMath nedir?" Eğer MyMathnesnenin bir tür tanımlamıyor, o zaman ben söyleyebilirim: Bir sınıf yapmazlar.

Ama dediğim gibi, (hatta şiddetle) bu konuda bana (özellikle Java ve C # geliştiricileri) katılmayacak birçok insan olduğunu biliyorum.

• Statik verilere ihtiyacınız varsa, statik yöntemler kullanın.
• Bunlar şablon işlevleriyse ve tüm işlevler için birlikte bir dizi şablon parametresi belirleyebilmek istiyorsanız, şablon sınıfında statik yöntemler kullanın.

Aksi takdirde, ad boşluklu işlevler kullanın.

Yorumlara yanıt olarak: evet, statik yöntemler ve statik veriler aşırı kullanılır. Bu yüzden yardımcı olabileceklerini düşündüğüm sadece iki ilgili senaryo sundum. OP'nin özel örneğinde (bir dizi matematik rutini), tüm rutinlere uygulanacak parametreleri (örneğin, bir çekirdek veri türü ve çıktı hassasiyeti) belirleme yeteneğini isterse, şöyle bir şey yapabilir:

template<typename T, int decimalPlaces>
class MyMath
{
   // routines operate on datatype T, preserving at least decimalPlaces precision
};

// math routines for manufacturing calculations
typedef MyMath<double, 4> CAMMath;
// math routines for on-screen displays
typedef MyMath<float, 2> PreviewMath;

Buna ihtiyacınız yoksa, elbette bir ad alanı kullanın.

Bir ad alanının bir sınıfa göre birçok avantajı olduğu için bir ad alanı kullanmalısınız:

• Her şeyi aynı başlıkta tanımlamanız gerekmez
• Başlıktaki tüm uygulamanızı göstermenize gerek yoktur
• usingSınıf üyesi olamazsınız ; yapabilirsinusingbir ad alanı üyesi
• using classYine de yapamazsınusing namespace çoğu zaman iyi bir fikir değil
• Bir sınıf kullanmak, gerçekten yokken oluşturulacak bazı nesnelerin olduğunu ima eder

Statik üyeler, bence, çok fazla kullanıldı. Çoğu durumda gerçek bir zorunluluk değildir. Statik üye işlevleri muhtemelen dosya kapsamı işlevleri olarak daha iyi durumdadır ve statik veri üyeleri daha iyi, hak edilmemiş bir üne sahip genel nesnelerdir.

Ad alanlarını tercih ederim, bu şekilde uygulama dosyasında anonim bir ad alanında özel verilere sahip olabilirsiniz (bu nedenle privateüyelerin aksine başlıkta hiç görünmek zorunda değildir ). Başka bir avantajı, usingad alanınız tarafından yöntemlerin istemcilerinin,MyMath::

Sınıfı kullanmak için bir neden daha - Erişim belirteçlerini kullanma seçeneği. Daha sonra, genel statik yönteminizi daha küçük özel yöntemlere ayırabilirsiniz. Genel yöntem birden çok özel yöntem çağırabilir.

Hem ad alanı hem de sınıf yönteminin kullanımları vardır. Ad alanı dosyalar arasında yayılma yeteneğine sahiptir, ancak tek bir dosyaya gitmek için ilgili tüm kodları uygulamanız gerekiyorsa bu bir zayıflıktır. Yukarıda belirtildiği gibi sınıf, sınıfta özel statik üyeler oluşturmanıza da izin verir. Uygulama dosyasının anonim ad alanında olabilir, ancak yine de onları sınıf içinde bulundurmaktan daha büyük bir kapsamdır.