Dosyalara bölme - ne kadar bölme?


9

Bileşen modeli yerine hiyerarşik bir varlık çerçevem ​​olduğunu söylersem. Gibi bir şey:
(Evet, bu oluşur)

Silah-> Silah-> AutomaticGun-> MP44
Veya daha klasik bir örnek:
Varlık-> MovableEntity-> Düşman-> WalkingEnemy

Okunabilirlik ve organizasyon için kaynak / başlık dosyalarını ne kadar ayırırsınız? Entity.cpp, MovableEntity.cpp, Enemy.cpp, vb. (Ya bir daha dil agnostik şekilde, bir Düşman dosyası ve her sınıf için bir dosya vs bir varlık dosyasında? Cinsinden)
Ayrıca, bu okunabilirliği ve organizasyon dışında başka bir şey etkileyecek?


1
Nitpicky, ancak language-agnosticyan etkiler için kullandığınız dile büyük ölçüde bağlı olduğundan uygun bir etiket olduğunu düşünmüyorum .
Tetrad

İyi bir nokta, sanırım tekrar etiketleyebilirim.
Komünist Ördek

Yanıtlar:


12

Bu tamamen bir tercih meselesi. Ancak, kişisel olarak daha fazla dosya tarafında hata yapmanın en iyi olduğuna inanıyorum. Java dosya başına bir sınıf gerektirir ; dosya adı sınıf adıyla aynıdır; bunu, bu iyi uygulamayı uygulamak için politika ile yaparlar (ancak temelde bu sorunu çözen alt sınıflara sahip olabilirsiniz).

Ayrıca, kaynak kontrol sistemleri bir dosyadaki değişiklikleri birleştirmede oldukça iyidir, ancak tamamen ayrı dosyalarda çalışıyorsanız daha az zahmetlidir. Kimin hangi sınıfı değiştirdiğini daha kolay görebilirsiniz. Başka bir geliştiricinin AllEntities.h dosyasında değişiklik yaptığını varsayalım; dosyayı açıp diff çıktısına bakana kadar hangi varlık (veya varlıklar) değiştirdiğine dair hiçbir fikriniz yok.

Bununla birlikte , sınıfla ilgili küçük yapıları ve numaralandırmaları bir sınıfın dosyasında gruplandırmak harika . Yalnızca tek bir sınıf tarafından kullanılan bir numaralandırmanız varsa, onu neden kendi dosyasına bölüyorsunuz? Sadece bir araya getirin. Ancak başka bir sınıf tarafından kullanılıyorsa (yani başka bir sınıf üyesi bu numaralandırma türündeyse), o zaman ona kendi dosyasını verme zamanı gelmiştir.


Kabul. Türlerinizin karmaşıklığı kesinlikle bir faktör olmalıdır. Diliniz kısmi sınıfları destekliyorsa (veya üye uygulamaları C ++ 'a benzer şekilde düzenlenebilirse), özellikle karmaşık türleri birden çok dosyaya bölmeyi bile öneririm. Örneğin, sınıfınızın uygulaması gereken (büyük) bir arabirim varsa, ancak kod oldukça genelse ve geri kalanıyla son derece alakalı değilse, bu kodu ayrı bir dosya / kısmi sınıfa ayırabilirsiniz. Numaralandırma türleri için, belirli bir ad alanı için tüm numaralandırmaları tek bir dosyaya yerleştirerek uzaklaşabileceğinizi düşünüyorum.
Mike Strobel

1
Numaralarınızı gruplandırmak, tek bir değeri değiştirmek, o ad alanında numaralandırma kullanan her dosyanın yeniden derlenmesine neden olacağı anlamına gelmiyor mu?
Komünist Ördek

Bu gerçekten dile bağlı, ama evet, kesinlikle bu etkiye sahip olabilir. Öncelikle C # (dosya-dosya derleme yok) geliştirdiğim için gerçekten bir sorun değil, ancak C ++ ve diğer dillerde sorunlu olabilir. Her zaman olduğu gibi, dikkate alınması gereken dile özgü faktörler vardır ve bu onlardan biri olacaktır :).
Mike Strobel

2

C / C ++ dışındaki birçok dil dosyalara kısıtlama getirir. Ricket, Java'nın 'dosya başına bir sınıftan' bahsetti; Python dosyaları ad alanı olarak kullanır; diğer diller genellikle bunların ruhunu kopyalar.

C veya C ++ kullanıyorsanız, daha fazla dahil edilen dosyalar genellikle dosya başına daha uzun derleme süreleri anlamına gelir; Öte yandan, küçük değişiklikler yaparken yeniden derlemek daha az demektir. Numaralandırmalar C'de ileri bildirilemediğinden, bağımlılık aklı için her zaman yalnızca diğer numaralandırmaları içeren başlık dosyalarına koymalısınız.

Aksi takdirde, Java'nın "sınıf başına bir dosya" makuldür, ancak Java uzun zamandır iç sınıfları destekledi - bir kap ve yineleyicinin bir iç sınıfı gibi. Benzer şekilde, başka herhangi bir dilde, başlık başına muhtemelen bir baskın kayıt / yapı / sınıf / tür / arayüz / blorb isteyeceksiniz, ancak ilgili yardımcıları veya kapsayıcıları da dahil etmeye karar verebilirsiniz.

(Bileşen modeli kullanmanıza gerek yoktur, ancak böyle derin ve spesifik bir sınıf hiyerarşiniz varsa, daha sonra kendinizden nefret edersiniz.)


Hiyerarşiyi örnek olarak kullanıyordum; Daha iyi ne demek istediğimi vurguladığını hissettim. Gerçek kodda, bileşenlere doğru çalışıyorum.
Komünist Ördek
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.