“Yo-yo probleminden kaçın”, “ilkel takıntıya” izin vermek için geçerli bir neden midir?

İlkel saplantı ne zamana göre kod kokusu değil midir? , Bir String nesnesi yerine bir posta kodunu temsil etmek için bir ZipCode nesnesi oluşturmalıyım.

Ancak deneyimlerime göre görmeyi tercih ederim

public class Address{
    public String zipCode;
}

onun yerine

public class Address{
    public ZipCode zipCode;
}

çünkü sonuncusunun benden programı anlamak için ZipCode sınıfına gitmemi gerektirdiğini düşünüyorum.

Ve her ilkel veri alanlarının bir yo-yo probleminden (bir anti-patern) muzdarip gibi hissettirdiği bir sınıfla değiştirilip değiştirilmediğini tanımlamak için birçok sınıf arasında geçiş yapmam gerektiğine inanıyorum .

Bu yüzden, ZipCode yöntemlerini yeni bir sınıfa taşımak istiyorum, örneğin:

Eski:

public class ZipCode{
    public boolean validate(String zipCode){
    }
}

Yeni:

public class ZipCodeHelper{
    public static boolean validate(String zipCode){
    }
}

bu yüzden sadece posta kodunu doğrulaması gereken kişi ZipCodeHelper sınıfına bağlı olacaktır. Ve ilkel saplantıyı korumanın başka bir "yararını" buldum: sınıfın, varsa serileştirilmiş hali gibi görünmesini sağlar: dize sütunu zipCode ile bir adres tablosu.

Sorum şu, "yo-yo probleminden kaçınmak" (sınıf tanımları arasında hareket etmek), "ilkel takıntıya" izin vermek için geçerli bir neden mi?

Varsayım, Address sınıfını anlamak için ZipCode sınıfına katılmanıza gerek olmadığıdır . Eğer ZipCode iyi tasarlanmışsa, sadece Address sınıfını okuyarak ne yaptığını açıkça belirtmelisiniz.

Programlar uçtan uca okunmaz - genellikle programlar bunu mümkün kılmak için çok karmaşıktır. Bir programdaki tüm kodu aynı anda aklınızdan çıkaramazsınız. Bu yüzden, programı anlamlı birimler halinde "parçalamak" için soyutlamalar ve enkapsülasyonlar kullanıyoruz, böylece programın bir kısmına (Adres sınıfını söyleyebiliyorsunuz) bağlı olduğu tüm kodları okumak zorunda kalmadan bakabiliyorsunuz.

Örneğin, String kodunda her karşılaştığınızda String kaynak kodunu okumayacağınıza eminim.

Sınıfı ZipCode'dan ZipCodeHelper olarak yeniden adlandırmak iki ayrı kavram olduğunu ileri sürüyor: bir posta kodu ve bir posta kodu yardımcısı. Yani iki kat daha karmaşık. Ve şimdi tip sistemi, aynı tipte olduklarından, rastgele bir dize ile geçerli bir posta kodu arasında ayrım yapmanıza yardımcı olamaz. Bu, “takıntı” nın uygun olduğu yerdir: İlkelde basit bir sarmalayıcı türünden kaçınmak istediğiniz için, daha karmaşık ve daha az güvenli bir alternatif öneriyorsunuz.

İlkel kullanımı, bu özel tipe bağlı olarak doğrulama ya da başka bir mantık bulunmadığı durumlarda IMHO tarafından doğrulanır. Ancak herhangi bir mantık eklediğiniz anda, bu mantığın tiple kapsanması çok daha kolaydır.

Serileştirme gelince, kullandığınız çerçevede bir sınırlama gibi geliyor düşünüyorum. Elbette, bir ZipCode'u bir dizeye seri hale getirebilmeli veya bir veritabanındaki bir sütuna eşleyebilmelisiniz.

Yapabilirseniz:

new ZipCode("totally invalid zip code");

Ve ZipCode için yapıcı şunları yapar:

ZipCodeHelper.validate("totally invalid zip code");

Sonra enkapsülasyonu kırdın ve ZipCode sınıfına aptalca bir bağımlılık ekledin. Yapıcı ise gelmez diyoruz ZipCodeHelper.validate(...)o zaman aslında getirmezsek kendi adasında mantığı izole ettik. Geçersiz posta kodları oluşturabilirsiniz.

validateYöntem zipcode sınıfına statik yöntem olmalıdır. Şimdi "geçerli" bir posta kodu bilgisi ZipCode sınıfı ile birlikte paketlenmiştir. Kod örnekleriniz Java'ya benziyorsa, yanlış bir format verilirse ZipCode yapıcısının bir istisna oluşturması gerekir:

public class ZipCode {
    private String zipCode;

    public ZipCode(string zipCode) {
        if (!validate(zipCode))
            throw new IllegalFormatException("Invalid zip code");

        this.zipCode = zipCode;
    }

    public static bool validate(String zipCode) {
        // logic to check format
    }

    @Override
    public String toString() {
        return zipCode;
    }
}

Yapıcı, formatı kontrol eder ve bir istisna atar, böylece geçersiz posta kodlarının oluşturulmasını önler ve statik validateyöntem, başka bir kod için kullanılabilir, bu nedenle formatı kontrol etme mantığı, ZipCode sınıfında kapsüllenir.

ZipCode sınıfının bu varyantında "yo-yo" yoktur. Sadece uygun Nesneye Yönelik Programlama olarak adlandırılır.

Ayrıca burada ZipCodeFormat veya PostalService (örneğin PostalService.isValidPostalCode (...), PostalService.parsePostalCode (...), vb.) Bir başka sınıfa ihtiyaç duyan uluslararasılaşmayı da görmeyeceğiz.

Bu soru ile çok güreşirseniz, belki de kullandığınız dil iş için doğru bir araç değildir? Bu tür "etki alanı tarafından yazılan ilkellerin", örneğin F # ile ifade edilmesi son derece kolaydır.

Örneğin, şöyle yazabilirsiniz:

type ZipCode = ZipCode of string
type Town = Town of string

type Adress = {
  zipCode: ZipCode
  town: Town
  //etc
}

let adress1 = {
  zipCode = ZipCode "90210"
  town = Town "Beverly Hills"
}

let faultyAdress = {
  zipCode = "12345"  // <-Compiler error
  town = adress1.zipCode // <- Compiler error
}

Bu, farklı varlıkların kimliklerini karşılaştırmak gibi yaygın hatalardan kaçınmak için gerçekten yararlıdır. Ve bu ilkel ilkeler bir C # veya Java sınıfından çok daha hafif olduğundan, sonunda onları gerçekten kullanırsınız.

Cevap tamamen ZIP kodlarıyla aslında ne yapmak istediğinize bağlıdır. İşte iki aşırı olasılık:

(1) Tüm adreslerin tek bir ülkede olması garanti edilir. Hiç istisna yok. (Örneğin, yabancı bir müşteri veya yabancı bir müşteri için çalışırken özel adresi yurtdışında olan çalışanlar yok.) Bu ülkenin ZIP kodları var ve hiçbir zaman ciddi bir sorun yaşamaması bekleniyor (yani serbest biçimli girdi gerektirmiyor) "şu anda D4B 6N2, ancak bu her 2 haftada bir değişiyor" gibi. ZIP kodları sadece adresleme için değil, ödeme bilgilerinin veya benzeri amaçların doğrulanması için kullanılır. - Bu şartlar altında, bir ZIP kodu sınıfı çok mantıklıdır.

(2) Adresler hemen hemen her ülkede olabilir, bu nedenle ZIP kodları olan veya olmayan (ve binlerce garip istisna ve özel durum içeren) düzinelerce veya yüzlerce adresleme programı söz konusudur. Bir "ZIP" kodu gerçekten yalnızca, ZIP kodlarının kendilerine vermeyi unutmamak için kullanılan ülkelerden insanlara hatırlatması istenir. Adresler yalnızca birisi hesabına erişimini kaybederse ve isimlerini ve adreslerini ispat edebilmeleri durumunda erişimin geri kazanılmasını sağlamak için kullanılır. - Bu şartlar altında, ilgili tüm ülkeler için ZIP kodu sınıfları çok büyük bir çaba olacaktır. Neyse ki onlar gerekli değildir.

Diğer cevaplar, OO alan modellemesi ve değerinizi temsil etmek için daha zengin bir tip kullanma hakkında konuştu.

Kabul etmiyorum, özellikle de gönderdiğiniz örnek kod verildiğinde.

Fakat bunun da sorunuzun başlığına cevap verip vermediğini merak ediyorum.

Şu senaryoyu inceleyin (üzerinde çalıştığım gerçek bir projeden çıkarılan):

Merkezi sunucunuzla konuşan bir saha cihazında uzak bir uygulamanız var. Aygıt girişi için DB alanlarından biri, alan aygıtının bulunduğu adres için bir posta kodudur. Posta kodunu umursamıyorsunuz (veya bu konuda adresin geri kalanından herhangi birini). Bunu önemseyen herkes, bir HTTP sınırının diğer tarafındadır: Siz sadece veriler için tek bir gerçeğin kaynağı olursunuz. Etki alanı modellemenizde yeri yok. Siz sadece kaydedin, doğrulayın, saklayın ve istek üzerine başka bir noktaya işaret etmek için bir JSON blobunda karıştırın.

Bu senaryoda, eki bir SQL regex kısıtlamasıyla (veya ORM eşdeğeriyle) doğrulamanın ötesinde bir şey yapmak muhtemelen YAGNI çeşidinin sorumluluğudur.

ZipCodeSenin eğer soyutlama sadece anlamlı olamaz Addresssınıfı da yoktu TownNameözelliği. Aksi takdirde, yarım bir soyutlamaya sahipsiniz: posta kodu kasabayı belirtir, ancak bu iki bilgi parçası farklı sınıflarda bulunur. Hiç mantıklı gelmiyor.

Ancak, o zaman bile, hala ilkel takıntı doğru bir uygulama (ya da daha doğrusu çözüm) değildir; Anladığım kadarıyla iki şeye odaklanıyor:

1. İlkellerin, özellikle ilkel bir koleksiyon gerekli olduğunda, bir yöntemin girdi (veya çıktı) değerleri olarak kullanılması.
2. Bunların bir kısmının kendi alt sınıflarına ayrılıp ayrılmayacağını yeniden düşünmeden zaman içerisinde ekstra özellikler yetiştiren sınıflar.

Senin durumun da değil. Bir adres açıkça gerekli özellikleri olan (cadde, numara, posta kodu, kasaba, eyalet, ülke, ...) iyi tanımlanmış bir kavramdır. Tek bir sorumluluğa sahip olduğu için bu verileri bölmek için çok az veya hiç sebep yok : Dünya üzerinde bir yer belirleyin. Bir adres anlamlı olmak için bu alanların tümünü gerektirir . Yarım adres anlamsız.

Bu şekilde, daha fazla alt bölüme ayırmanız gerekmediğini biliyorsunuz: daha fazla parçalara ayırmak, Addresssınıfın işlevsel niyetinden düşecektir . Benzer şekilde, (bağlı bir kişi olmadan) etki alanınızdaki anlamlı bir kavram olmadığı sürece Name, Personsınıfta kullanılacak bir alt sınıfa ihtiyacınız yoktur Name. Hangi (genellikle) değil. İsimler insanları tanımlamak için kullanılır, genellikle kendi başlarına hiçbir değeri yoktur.

Makaleden:

Daha genel olarak, yo-yo problemi, bir insanı bir kavramı anlamak için farklı bilgi kaynakları arasında çevirmeye devam etmesi gereken herhangi bir durumu da ifade edebilir.

Kaynak kodu , yazıldığından çok daha sık okunur . Bu nedenle, yo-yo problemi, birçok dosya arasında geçiş yapmak zorunda kalmak bir konudur.

Bununla birlikte, hayır , yo-yo problemi derinlemesine bağımlı modüller veya sınıflarla (bunlar arasında ileri geri gelen) uğraşırken çok daha anlamlı hisseder. Bunlar okumak için özel bir kabus ve muhtemelen yo yo probleminin aklındakilerdi.

Ancak - evet , çok fazla soyutlama katmanından kaçınmak önemlidir!

Tüm önemsiz olmayan soyutlamalar, bir dereceye kadar, sızdırıyor. - Sızdıran Soyutlamalar Kanunu.

Örneğin, mmmaaa’nın " Adres sınıfını anlamak için ZipCode sınıfını [(ziyaret et]] 'e ihtiyacınız yok " ) cevabında yapılan varsayımlara katılmıyorum . Tecrübelerim senin yaptığın en azından ilk birkaç kez kodu okudun. Ancak, diğerlerinin de belirttiği gibi, bir sınıfın uygun olduğu zamanlar vardır ZipCode.

YAGNI (Ya vermeyecek mi ihtiyacınız O) (çok fazla katmanlarla kodu) lazanya kodunu önlemek için takip etmenin tam kalıptır - soyutlamalar gibi türleri olarak ve sınıfları programcı orada yardım etmek ve bunlar olmadıkça kullanılmamalıdır vardır bir yardım.

Şahsen "kod satırlarını kaydetmeyi" (ve tabii ki ilgili "dosyaları / modülleri / sınıfları kaydet" vb.) Hedefliyorum. Bana “ilkel takıntılı” sıfatını uygulayacak bazılarının olduğuna eminim - etiketler, kalıplar ve kalıplaşma kalıpları için endişelenmekten ziyade kolay anlaşılır bir kodun olmasını daha önemli buluyorum . Bir fonksiyonun ne zaman, bir modül / dosya / sınıf ne zaman yaratılacağı veya bir fonksiyonun ortak bir yere ne zaman konulacağı doğru bir seçimdir. Yaklaşık 3-100 satır işlevi, 80-500 satır dosyası ve yeniden kullanılabilir kütüphane kodu için "1, 2, n" ( SLOC - yorumlar veya kazan plakası dahil değil; zorunlu olarak her satır için en az 1 ek SLOC istiyorum.) Basmakalıp).

Çoğu olumlu kalıp, geliştiricilerin ihtiyaç duyduklarında tam olarak bunu yapmalarından kaynaklanmaktadır . Nasıl okunabilir kod yazılacağını öğrenmek, çözmek için aynı problemi olmayan desenleri uygulamaya çalışmaktan çok daha önemlidir. Herhangi bir iyi geliştirici, alışılmadık bir durumda daha önce görmeden fabrika şablonunu kendi problemine uygun olduğu durumlarda uygulayabilir. Fabrika modelini, gözlemci modelini kullandım ve muhtemelen adlarını bilmeden yüzlerce kişi kullandım (yani, "değişken atama modeli" var mı?). Eğlenceli bir deneme için - JS diline kaç tane GoF paterni yerleştirildiğini görün - 2009'da 12-15 yıl sonra saymayı kestim. Fabrika modeli bir nesneyi bir JS kurucusundan döndürmek kadar basit, örneğin - gerek yok Bir WidgetFactory.

Yani - evet , bazen ZipCode iyi bir sınıftır. Ancak, hayır , yo-yo problemi kesinlikle ilgili değil.

Yoyo problemi sadece ileri geri çevirmeniz gerektiğinde geçerlidir. Buna bir veya iki şey neden olur (bazen her ikisi de):

1. Kötü adlandırma ZipCode iyi görünüyor, ZoneImprovementPlanCode çoğu insan tarafından bakılmasını gerektirecek (ve etkilenmeyenlerin sayısı çok az).
2. Uygunsuz bağlantı ZipCode sınıfının bir alan kodu araması olduğunu söyleyin. İşe yarar olduğunu düşünebilirsiniz, çünkü kullanışlı, ancak gerçekten ZipCode ile ilgili değil ve onu içine sokmak artık insanların bir şeyler için nereye gideceğini bilmediği anlamına geliyor.

İsme bakabilir ve ne yaptığı hakkında makul bir fikre sahipseniz, yöntemler ve özellikler oldukça açık şeyler yaparsa, koda bakmanıza gerek kalmaz, sadece kullanabilirsiniz. İlk başta bütün sınıfların noktası budur - bunlar yalıtımlı olarak kullanılabilecek ve geliştirilebilecek modüler kod parçalarıdır. Sınıfın ne yaptığını görebilmesi için API dışında bir şeye bakmanız gerekiyorsa, bu en iyi ihtimalle kısmi bir başarısızlıktır.

Unutma, gümüş kurşun yok. Hızlı taranması gereken son derece basit bir uygulama yazıyorsanız, basit bir dize işi yapabilir. Ancak , zamanın% 98'inde DDD'de Eric Evans tarafından tanımlandığı gibi bir Değer Nesnesi , mükemmel bir seçim olacaktır. Değer nesnelerinin sağladığı tüm faydaları kolayca okuyabilirsiniz.