Java'da Asla Dizeler kullanmayın mu? [kapalı]

Kodunuzun anlamsallıktan yoksun olması için Java'da Strings kullanımından vazgeçen bir blog girişine rastladım, bunun yerine ince sarmalayıcı sınıfları kullanmanız gerektiğini önerdim. Bu, söz konusu girişin konuyu açıklamak için sunduğu önceki ve sonraki örneklerdir:

public void bookTicket(
  String name,
  String firstName,
  String film,
  int count,
  String cinema);

public void bookTicket(
  Name name,
  FirstName firstName,
  Film film,
  Count count,
  Cinema cinema);

Tecrübelerime göre, programlama bloglarını okudum,% 90’ın saçmalık olduğu sonucuna vardım, ancak bunun geçerli bir nokta olup olmadığını merak ediyorum. Her nasılsa bana doğru gelmiyor ama tam olarak programlama tarzına neyin yanlış geldiğini tam olarak belirleyemedim.

Kapsülleme programı değişime karşı korumak için var . Bir ismin temsili değişecek mi? Olmazsa, zamanınızı boşa harcıyorsunuz ve YAGNI başvuruyor.

Düzenleme: Blog gönderisini okudum ve temelde iyi bir fikri var. Sorun şu ki, onu çok fazla ölçeklendirdi. Gibi bir String orderId şey gerçekten kötü, çünkü muhtemelen "!"£$%^&*())ADAFVFgeçerli değil orderId. Bu String, geçerli orderIds değerlerinden çok daha olası değerleri temsil ettiği anlamına gelir . Ancak, a gibi bir şey için name, geçerli bir adın ne olabileceğini ya da olmayacağını tahmin edemezsiniz ve herhangi Stringbiri geçerli olabilir name.

İlk örnekte, olası girdileri yalnızca geçerli olanlara indirgiyorsunuz (doğru). İkinci durumda, olası geçerli girdilerin daraltılmasını sağlayamadınız.

Tekrar düzenle: Geçersiz giriş durumunu düşünün. "Gareth Gobulcoque" u sizin adınız olarak yazarsanız, aptalca görünecek, dünyanın sonu olmayacak. Geçersiz bir OrderID girerseniz, bunun basit bir şekilde işe yaramayacağına dair ihtimaller var.

Bu sadece delilik :)

• Sağduyu kullanın
• Fazla mühendis olmayın!
• Küçük basit tutun!
• İhtiyacın Olmayacak (YagNi)

Çoğunlukla yazar ile aynı fikirdeyim. Bir alana özgü herhangi bir davranış varsa, sipariş kimliğinin doğrulanması gibi, o zaman bu türü temsil edecek bir sınıf oluşturacağım. İkinci noktası daha da önemlidir: eğer bir adres gibi bazı kavramları temsil eden bir alan kümeniz varsa, o zaman bu kavram için bir sınıf oluşturun. Java ile programlama yapıyorsanız, statik yazım için yüksek bir fiyat ödersiniz. Elinden geldiğince tüm değerleri alabilirsin.

Yapma; işleri karmaşıklaştıracak ve ihtiyacın olmayacak

... 2 yıl önce buraya yazacağım cevap. Şimdi, yine de çok emin değilim; Aslında, son aylarda eski kodu bu formata taşımaya başladım, yapacak daha iyi bir şeyim olmadığı için değil, yeni özellikleri uygulamak veya var olanları değiştirmek için gerçekten gerekli olan şeylerdi. Buradaki diğer kişilerin bu kodu gördüğü otomatik isteksizlikleri anlıyorum, ancak bunun ciddi düşünceyi hak eden bir şey olduğunu düşünüyorum.

Yararları

Avantajlardan biri , kodu değiştirme ve uzatma yeteneğidir . Eğer kullanırsan

class Point {
    int x,y;
    // other point operations
}

etrafa birkaç tamsayı geçirmek yerine - ki maalesef birçok arayüzün yaptığı bir şey - o zaman daha sonra başka bir boyut eklemek çok daha kolay hale gelir. Veya türünü değiştirin double. Kullanırsanız List<Author> authorsveya List<Person> authorsonun yerine List<String> authorsdaha sonra yazarın temsil ettiği şeye daha fazla bilgi eklemek daha kolay hale gelir. Bu şekilde yazmak, açık bir şekilde belirttiğimi hissediyormuş gibi hissettiriyor, ancak pratikte, özellikle başlangıçta bariz olmadığı durumlarda, kendimden bu kadar çok tel kullandım. dizi.

Şu anda kodum boyunca iç içe geçmiş bazı dize listelerini yeniden düzenlemeye çalışıyorum çünkü orada daha fazla bilgiye ihtiyacım var ve acıyı hissediyorum: \

Bunun ötesinde, blog yazarıyla daha semantik bilgi taşıdığı ve okuyucunun anlamasını kolaylaştırdığı konusunda hemfikirim . Parametrelere genellikle anlamlı adlar verilmiş ve özel bir dokümantasyon satırı elde edilmiş olsa da, bu genellikle alanlar veya yerliler için geçerli değildir.

Nihai yarar, bariz nedenlerden dolayı tür güvenliğidir , ancak gözlerim burada küçük bir şey.

Dezavantajları

Yazması daha uzun sürer . Küçük bir sınıf yazmak , özellikle bu derslerin çoğuna ihtiyacınız varsa , hızlı ve kolaydır ancak zahmetsiz değildir . Kendinizi her 3 dakikada bir yeni sarmalayıcı sınıfı yazmak için durdurarak bulursanız, konsantrasyonunuza da zarar verebilir. Bununla birlikte, bu çaba durumunun genellikle herhangi bir kod parçasını yazmanın ilk aşamasında gerçekleşeceğini düşünmek isterim; Varlıkların dahil olması gerekenler hakkında genellikle çok iyi bir fikir edinebilirim.

Çok fazla gereksiz ayarlayıcı (veya inşaat) ve alıcı içerebilir . Blog yazarı, new Point(x(10), y(10))bunun yerine gerçekten çirkin bir örnek veriyor ve new Point(10, 10)bir kullanımın Math.max(p.x.get(), p.y.get())bunun yerine bunun gibi şeyleri de içerebileceğini eklemek istiyorum Math.max(p.x, p.y). Ve uzun kod genellikle okunması daha zor ve adil bir şekilde kabul edilir. Ancak tüm dürüstlük içerisinde, nesnelerin etrafından dolaştığı bir sürü kod hissi duyuyorum ve yalnızca bazı yöntemler yaratıyor ve daha da azının detaylarına (hatta OOPy değil) erişmesi gerekiyor.

tartışılabilir

Bunun kodun okunabilirliği konusunda yardımcı olup olmadığını tartışmalı olarak söyleyebilirim . Evet, daha fazla anlamsal bilgi, fakat daha uzun kod. Evet, her bir yerel halkın rolünü anlamak daha kolaydır, ancak belgelerini okumadığınız sürece onunla neler yapabileceğinizi anlamak zordur.

Diğer programlama okullarında olduğu gibi, bunu da aşırılıklara götürmenin sağlıksız olduğunu düşünüyorum. Kendimi hiç x ve y koordinatlarını farklı bir tip olarak ayırırken görmüyorum. Bir yeterli Countolduğunda gerekli olduğunu sanmıyorum int. unsigned intC'deki kullanımdan hoşlanmıyorum - teorik olarak iyi olsa da, sadece size yeterli bilgi vermez ve bu büyülü -1'i desteklemek için kodunuzun daha sonra uzatılmasını yasaklar. Bazen sadelik gerekir.

Bence blog yazısı aşırı tarafta. Fakat genel olarak, acı verici deneyimlerden arkasındaki temel fikrin doğru şeylerden yapıldığını öğrendim.

Aşırı tasarlanmış kod için derin bir isteksizlik var. Ben gerçekten yapıyorum. Fakat doğru kullanılırsa, bu fazla mühendislik olduğunu sanmıyorum.

Her ne kadar fazla abartılsa da, çoğu zaman gördüğüm şeylerin yeterince geliştirilmediğini düşünüyorum.

Sadece "Güvenlik" değil, Java ile ilgili gerçekten güzel şeylerden biri, herhangi bir kütüphane yöntemi çağrısının ihtiyaç duyduğu / beklediği şeyleri hatırlama / çözme konusunda size çok yardımcı olmasıdır.

WORST (bugüne kadar) Çalıştığım Java kütüphanesi, Smalltalk'a çok düşkün olan bir kişi tarafından yazılmış ve GUI kütüphanesini daha sonra smalltalk gibi hareket etmesini sağlayacak şekilde modellemiştir - her yöntemin olması aynı temel nesneyi kullanmakta, ancak temel nesnenin kullanabileceği her şeyi KULLANABİLEMEZDİ, bu yüzden neyin işe yarayacağını tahmin etmeye başladınız ve çalışma zamanına kadar başarısız olup olmadığınızı bilmiyordunuz (Eskiden her zaman başa çıkmam gereken bir şey) C) çalışıyordu.

Başka bir konu - Dizeleri, girişleri, koleksiyonları ve dizileri nesneler olmadan geçirirseniz, sahip olduğunuz tek şey anlamsız veri toplarıdır. Bu, "bazı uygulamaların" kullanacağını kütüphaneler açısından düşündüğünüzde doğal görünür, ancak bir uygulamanın tamamını tasarlarken, verilerin tanımlandığı ve yalnızca düşündüğü yerdeki tüm verilerinize anlam (kod) atamak çok daha yararlı olur. Bu üst düzey nesnelerin nasıl etkileşime girdiği ile ilgili terimler Nesneler yerine ilkellerin etrafından geçiyorsanız, o zaman - tanım gereği - verileri tanımlandığı yerden farklı bir yerde değiştiriyorsunuzdur (Bu, aynı zamanda Setters ve Getters'ı gerçekten sevmiyorum - aynı konsept, sizin olmayan verilerde).

Son olarak, her şey için ayrı nesneler tanımlarsanız, her şeyi doğrulamak için her zaman harika bir yeriniz vardır - örneğin, posta kodu için bir nesne oluşturursanız ve daha sonra, posta kodunun her zaman sahip olduğunuz 4 basamaklı uzantıyı içermesini sağlamalısınız. koymak için mükemmel bir yer.

Bu aslında kötü bir fikir değil. Bunu düşününce aşırı yapılandırıldığını bile söyleyeceğime bile emin değilim, neredeyse her şekilde çalışmak daha kolay - bir istisna küçük sınıfların çoğalması olmasına rağmen, Java sınıfları çok hafif ve kolaydır bunun neredeyse zor bir maliyet olduğunu yazmak (üretilebilirler bile).

Gerçekten çok fazla sınıf tanımlanmış iyi yazılmış bir java projesi görmek isterdim (Bunu programlamayı zorlaştırdı), çok fazla ders almanın mümkün olmadığını düşünmeye başladım.

Bu konsepte başka bir başlangıç ​​noktasından bakmanız gerektiğini düşünüyorum. Bir veritabanı tasarımcısının bakış açısına bir göz atın: ilk örnekte geçen türler, parametrelerinizi benzersiz bir şekilde tanımlamaz, tek başına yararlı bir yoldur.

public void bookTicket(
  String name,
  String firstName,
  String film,
  int count,
  String cinema);

Bilet rezervasyonu yapan asıl müşteriyi belirtmek için iki parametre gerekir, aynı isimlerle iki farklı filminiz olabilir (örn. Remake), farklı isimlerle aynı filme sahip olabilirsiniz (örneğin çeviriler). Belirli bir sinema salonu zincirinin farklı şubeleri olabilir, bu yüzden bununla nasıl bir ipte ve tutarlı bir şekilde başa çıkacaksınız (örneğin kullanıyorsunuz $chain ($city)ya $chain in $cityda hatta başka bir şey kullanıyorsunuz ve bunun nasıl olduğundan emin olacaksınız? Aslında en kötüsü patronunuzu iki parametre ile belirtmektir, hem ad hem de soyadının belirtilmiş olması geçerli bir müşteriyi garanti etmez (ve iki John Doeayı ayırt edemezsiniz ).

Bunun cevabı türleri bildirmektir, ancak bunlar yukarıda gösterdiğim gibi nadiren ince ambalajlar olacaktır. Büyük olasılıkla, veri depolama alanınız olarak işlev görürler veya bir tür veritabanına bağlanırlar. Yani bir Cinemanesnenin büyük olasılıkla bir adı, yeri ve ... ve bu gibi belirsizliklerden kurtulacaksınız. Eğer ince sargılarsa, tesadüf eseridirler.

Bu yüzden, IMHO blog yazısı sadece "doğru tiplerden geçtiğinizden emin olun" diyor, yazarı özellikle temel veri tiplerinde (yanlış mesaj olan) seçim yapmak için aşırı kısıtlı bir seçim yaptı.

Önerilen alternatif daha iyidir:

public void bookTicket(
  Name name,
  FirstName firstName,
  Film film,
  Count count,
  Cinema cinema);

Öte yandan, blog yazısının her şeyi sarmalamak için fazla ileri gittiğini düşünüyorum. Countçok genel, elma veya portakalları bununla sayabilir, ekleyebilir ve hala ellerimde tip sisteminin saçma sapan işlemler yapmama izin verdiği bir durum olabilir. Elbette blogdakiyle aynı mantığı uygulayabilir ve türleri tanımlayabilirsiniz CountOfOranges, vb.

Buna değer, aslında gibi bir şeyler yazmak

public Ticket bookTicket(
  Person patron,
  Film film,
  int numberOfTickets,
  Cinema cinema);

Uzun lafın kısası: saçma sapan değişkenleri geçmemelisiniz; gerçekte, gerçek nesneyi belirlemeyen bir değeri gerçekten belirlediğiniz zamanlar, bir sorgu çalıştırdığınızda (örn. public Collection<Film> findFilmsWithTitle(String title)) veya bir kavram kanıtı hazırladığınızda gerçekleşir. Böylece çok genel bir tür (a ile temsil örneğin bir film kullanmayın, temiz senin tipin sistemini tutun Stringyapmacık) ya da çok kısıtlayıcı / spesifik / (örn Countyerine int). Mümkün ve uygulanabilir olduğunda, nesnenizi benzersiz ve açık bir şekilde tanımlayan bir tür kullanın.

düzenleme : daha kısa bir özeti. Küçük uygulamalar için (örneğin kavramların ispatı): neden karmaşık bir tasarımla uğraşmıyorsunuz? Sadece kullanın Stringya da intdevam edin.

Büyük uygulamalar için: basit bir veri türüne sahip tek bir alandan oluşan çok sayıda sınıfınız olması muhtemel midir? Eğer böyle küçük sınıflarınız varsa, "normal" nesneleriniz var, orada özel bir şey yok.

Dizeleri kapsülleme fikrini hissediyorum ... ... tamamlanmamış bir tasarım: küçük uygulamalar için aşırı karmaşık, büyük uygulamalar için yeterince tamamlanmamış.

Bana göre bunu yapmak C # bölgesindeki bölgeleri kullanmakla aynı. Genel olarak, kodunuzu okunabilir hale getirmek için bunun gerekli olduğunu düşünüyorsanız, zamanınızı harcamalısınız.

Gerçekten iyi yazılmış bir fikir olduğunu ve çok iyi yazılmış bir typedef benzeri özelliğe sahip olduğunu söyleyebilirim.

Java'da buna sahip değilsiniz, bu nedenle bunlar için tamamen yeni bir sınıf oluşturmak, maliyetin muhtemelen faydadan ağır basacağı anlamına gelir. Ayrıca, değişken / parametre adlandırma konusunda dikkat ederek faydadan% 80 elde edebilirsiniz.

Bu iyi olurdu, IF String (tamsayı sonu ve ... sadece String hakkında konuşmak) son olamazdı, bu yüzden bu sınıflar bazı (sınırlı) bir dize anlamlı olabilirdi ve hala nasıl işleneceğini bilen bağımsız bir nesneye gönderilebilirdi. temel tür (ileri geri konuşmadan).

Ve örneğin "şerefsiz" ler artar. tüm isimlerdeki kısıtlamalar.

Ancak, bazı uygulamalar oluştururken (kütüphane değil), onu düzeltmek her zaman mümkün. Bu yüzden onsuz başlamayı tercih ederim.

Bir örnek vermek gerekirse: şu anda geliştirilen sistemimizde, bazen aynı varlık olsa bile, birden fazla tür tanımlayıcı ile (harici sistemlerin kullanımı nedeniyle) tanımlanabilecek birçok farklı varlık vardır. Tüm tanımlayıcılar Dizelerdir - eğer birileri parametre olarak hangi tür bir kimliğin geçmesi gerektiğini karıştırırsa, derleme zamanı hatası gösterilmez, ancak program çalışma zamanında patlayacaktır. Bu oldukça sık olur. Bu nedenle, bu ilkenin temel amacının değişime karşı (aynı zamanda hizmet etmesine rağmen) korunmak değil, kendimizi böceklerden korumak olduğunu söylemeliyim. Her neyse, eğer biri bir API tasarlarsa, etki alanı kavramlarını yansıtmak zorundadır, bu nedenle etki alanına özgü sınıfları tanımlamak kavramsal olarak yararlıdır - her şey geliştiricilerin aklında düzen olup olmamasına bağlıdır,