Aynı ada sahip, ancak ad alanlarında farklılık gösteren sınıfları olan bazı kodlar (önemliyse C #) çalıştırdım. Hepsi aynı mantıksal şeyi temsil etme eğilimindedir, ancak genellikle aynı nesnenin farklı "görünümleri" dir. Farklı ad alanları bazen aynı çözümün ve hatta aynı dll'nin bir parçasıdır.

Düşüncelerim var, ancak mevcut araçların akıllıca kullanılması veya kaçınılması için bir desen olarak kabul edilecek bu uygulama hakkında kesin bir şey bulamadım.

Şirin adlandırma ile ilgili bu soru bu konuda dokunuşlar, ancak diğer yönden. İsimleri netleştirmek, muhtemelen bu sorunun ortadan kaldırmak istediği keyfi ve yaygın bir önek gerektirecektir.

Bu uygulamanın etrafındaki yönergeler nelerdir?

Projelerimden birinde de gördükten ve üzerinde çalıştıktan sonra bu kullanıma karşı bir cevap vermeye çalışacağım.

Kod okunabilirliği

Her şeyden önce, kod okunabilirliğinin önemli olduğunu ve bu uygulamanın buna ters olduğunu düşünün. Birisi bir parça kod okur ve diyelim ki bir işlevi var doSomething(Employee e). Bu artık okunabilir değil, çünkü Employeefarklı paketlerdeki 10 farklı sınıf nedeniyle , girdinizin gerçekte ne olduğunu öğrenmek için önce ithalat beyanına başvurmanız gerekecektir.

Bununla birlikte, bu üst düzey bir görünümdür ve çoğu zaman kimsenin umursamadığı, hatta bulduğu rastgele isim çatışmaları var, çünkü anlamı kalan koddan ve hangi pakette olduğunuzdan türetilebilir. yerel olarak hiçbir sorun yoktur, çünkü Employeebir hrpaketin içinde görürseniz , çalışanın İK görünümünden bahsettiğimizi bilmeniz gerekir.

Bu paketleri terk ettiğiniz anda işler dağılıyor. Farklı bir modül / paket / vb. Çalıştıktan ve bir çalışanla çalışmanız gerektiğinde, türünü tam olarak nitelemiyorsanız okunabilirlikten zaten ödün vermiş olursunuz. Ayrıca, 10 farklı Employeesınıfa sahip olmak, IDE'nizin otomatik tamamlanmasının artık çalışmadığı ve çalışan türünden manuel olarak seçim yapmanız gerektiği anlamına gelir.

Kod çoğaltma

Bu sınıfların her birinin doğası gereği birbiriyle ilişkili olduğundan, çoğaltma nedeniyle kodunuzun bozulması gerekir. Çoğu durumda, her bir sınıfın uygulamak zorunda olduğu bir çalışanın adı veya bir kimlik numarası gibi bir şeye sahip olacaksınız. Her sınıf kendi görüşünü eklese de, temeldeki çalışan verilerini paylaşmazlarsa, o zaman büyük kitleler yararsız, ama pahalı kodlarla karşılaşacaksınız.

Kod karmaşıklığı

Ne sorabilirsiniz ki bu kadar karmaşık olabilir? Sonuçta, sınıfların her biri istediği kadar basit tutabilir. Gerçekten sorun haline gelen şey, değişiklikleri nasıl yaydığınızdır. Oldukça zengin özelliklere sahip bir yazılımda, çalışan verilerini değiştirebilirsiniz - ve bunu her yere yansıtmak isteyebilirsiniz. Bir bayan sadece evli olduğunu söyle ve onu adlandırmak zorunda XiçinYbu nedenle. Bunu her yerde yapmak için yeterince zor, ama tüm bu farklı sınıflara sahip olduğunuzda daha da zor. Diğer tasarım seçeneklerinize bağlı olarak, bu, sınıfların her birinin kendi tür dinleyicisini veya değişikliklerden haberdar edilecek bir şeyi uygulaması gerektiği anlamına gelebilir - bu da temel olarak uğraşmanız gereken sınıf sayısına uygulanan bir faktöre dönüşür . Ve elbette daha fazla kod çoğaltma ve daha az kod okunabilirliği. Bu gibi faktörler karmaşıklık analizinde göz ardı edilebilir, ancak kod tabanınızın boyutuna uygulandığında rahatsız edici.

Kod iletişimi

Tasarım seçenekleriyle de ilgili olan kod karmaşıklığı ile ilgili yukarıdaki sorunların yanı sıra, üst düzey tasarım netliğinizi azaltır ve alan adı uzmanlarıyla düzgün iletişim kurma yeteneğini kaybedersiniz. Mimariyi, tasarımları veya gereksinimleri tartışırken artık basit ifadeler yapmakta özgür değilsiniz given an employee, you can do .... Bir geliştirici artık employeeo noktada gerçekten ne anlama geldiğini bilemeyecek . Her ne kadar bir alan adı uzmanı bunu bilecek olsa da. Hepimiz yapıyoruz. bir çeşit. Ancak yazılım açısından artık iletişim kurmak o kadar kolay değil.

Problemden nasıl kurtulurum

Bunun farkında olma ve sonra eğer ekibiniz mücadele için bir sorun yeterince büyük olduğunu kabul eder, o zaman başa bir şekilde dışarı işe sahip olacaktır. Genellikle, yöneticinizden çöpü çıkarabilmeleri için tüm ekibe bir hafta izin vermesini isteyemezsiniz. Yani özünde, bu sınıfları birer birer kısmen ortadan kaldırmak için bir yol bulmanız gerekecek. Bunun en önemli kısmı - tüm ekiple - Employeegerçekten ne olduğuna karar vermektir . Do not tek tanrı-çalışanın bireysel özelliklerin hepsi entegre. Daha çok çekirdek çalışanı düşünün ve en önemlisi bu Employeesınıfın nerede kalacağına karar verin .

Kod incelemeleri yaparsanız, sorunun en azından daha fazla büyümediğinden emin olmak özellikle kolaydır, yani başka bir tane Employeedaha eklemek istediklerinde herkesi kendi yolunda durdurun . Ayrıca, yeni alt sistemlerin kararlaştırılanlara uymasına Employeeve eski sürümlere erişmesine izin verilmemesine dikkat edin.

Programlama dilinize bağlı olarak, sonunda ortadan kaldırılacak sınıfları, @Deprecatedekibinizin değiştirilmesi gereken bir şeyle çalıştıklarını hemen fark etmelerine yardımcı olmak gibi bir şeyle işaretlemek de isteyebilirsiniz .

Eski çalışan sınıflarından kurtulmak için, her bir vaka için en iyi nasıl ortadan kaldırılacağına karar verebilir veya sadece ortak bir kalıp üzerinde anlaşabilirsiniz. Sınıf adını iliştirebilir ve gerçek çalışanın etrafına sarabilir, desenleri (dekoratör veya adaptör akla gelir) veya veya veya kullanabilirsiniz.

Uzun bir hikaye kısaca anlatmak gerekirse: Bu "uygulama" teknik olarak sağlamdır, ancak yalnızca yolun ilerisinde gerçekleşecek gizli maliyetlerle doludur. Sorundan hemen kurtulamayabilirsiniz, ancak zararlı etkilerini içererek hemen başlayabilirsiniz.

Scala Koleksiyon Çerçevesi bunun güzel bir örneğidir. Değişken ve değişmez koleksiyonların yanı sıra seri ve paralel (ve gelecekte de dağıtılabilir) koleksiyonlar vardır. Yani, örneğin, dört Mapözellik vardır:

scala.collection.Map
scala.collection.immutable.Map
scala.collection.mutable.Map
scala.collection.concurrent.Map

artı üç ParMaps:

scala.collecion.parallel.ParMap
scala.collecion.parallel.immutable.ParMap
scala.collecion.parallel.mutable.ParMap

Daha da ilginç:

scala.collection.immutable.Map            extends scala.collection.Map
scala.collection.mutable.Map              extends scala.collection.Map
scala.collection.concurrent.Map           extends scala.collection.mutable.Map

scala.collecion.parallel.ParMap           extends scala.collection.Map
scala.collecion.parallel.immutable.ParMap extends scala.collecion.parallel.ParMap
scala.collecion.parallel.mutable.ParMap   extends scala.collecion.parallel.ParMap

Yani, ParMapuzanır ParMapuzanır Mapve Mapuzanır Mapuzanır Map.

Ama yüzleşelim: onlara başka ne diyeceksin? Bu çok mantıklı. İsim alanları bunun için!

Bu, esasen karşıt iki cevabın her ikisinin de doğru olduğu gerçekten ilginç bir soru. İşte benim bir proje hakkında yaptığımız bu tartışmanın gerçek dünya örneği .

@Jorg ve @Frank'in iki cevabından yararlanarak, şu ana kadar bir yöne veya diğerine gitmek istemenizi sağlayacak çok dikkat çekici iki husus olduğunu düşünüyorum:

1. Aynı kod bağlamında aynı adlı sınıflardan birden fazlasının kullanılması gerekebileceğini düşünüyorsanız, bu aynı adı kullanmamak için bir nedendir. Yani, birlikte çalışmanız gerekiyorsa, hr.Employeeancak aynı zamanda izinlere de bakmanız gerekiyorsa security.Employee, can sıkıcı gerçek hızlı olacak.
2. Tersine, aynı ada sahip sınıflarınızın hepsi aynı veya çok benzer API'lara sahipse , aynı adı farklı ad alanlarıyla ne zaman kullanmanız gerektiğine iyi bir örnektir . Scala örneği, tüm Mapsınıfların aynı arabirimi uyguladığı veya birbirlerinin alt sınıfları olduğu tam olarak budur . Bu durumda, belirsizlik veya "karışıklık" tartışmalı olarak iyi bir şey olarak adlandırılabilir, çünkü kullanıcı haklı olarak sınıfın veya arayüzün tüm uygulamalarına aynı şekilde davranabilir ... bu da arayüzlerin ve alt sınıfların noktasıdır.