Bir nesnenin bütün eserini yapıcıda yapmak için bir sebep var mı?

Bunun benim kodum ya da iş arkadaşımın kodu olmadığını söyleyerek bunu daha önce belirteyim. Yıllar önce, şirketimiz daha küçükken, kapasitemize sahip olmadığımız için ihtiyaç duyduğumuz bazı projelerimiz vardı, bu yüzden dışarıdan tedarik edildiler. Şimdi, genel olarak dış kaynak kullanımına veya müteahhitlere karşı hiçbir şeyim yok, ancak ürettikleri kod temeli bir WTF kütlesidir. Olduğu söyleniyor, işe yarıyor (çoğunlukla), sanırım gördüğüm dış kaynaklı projelerin ilk% 10'unda.

Şirketimiz büyüdükçe evimizdeki gelişmeyi daha da arttırmaya çalıştık. Bu özel proje kucağıma düştü, ben de üzerinden geçtim, temizledim, testler ekledim, vb.

Çok tekrarlanan gördüğüm tek bir kalıp var ve o kadar akıl almaz derecede korkunç görünüyor ki, belki bir sebep olup olmadığını merak ettim ve göremiyorum. Model, genel metot veya üyelere sahip olmayan, sadece nesnenin tüm çalışmalarını yapan bir kamu kurucusu olan bir nesnedir.

Örneğin, (kod önemlidir, eğer önemliyse, ancak umarım bu daha genel bir soru olur):

public class Foo {
  private int bar;
  private String baz;

  public Foo(File f) {
    execute(f);
  }

  private void execute(File f) {
     // FTP the file to some hardcoded location, 
     // or parse the file and commit to the database, or whatever
  }
}

Merak ediyorsanız, bu kod türü genellikle aşağıdaki şekilde adlandırılır:

for(File f : someListOfFiles) {
   new Foo(f);
}

Şimdi, uzun zaman önce döngüdeki somutlaştırılmış nesnelerin genellikle kötü bir fikir olduğu ve inşaatçıların minimum çalışma yapması gerektiği öğretildi. Bu koda baktığımızda, yapıcıyı bırakmanın ve executegenel statik bir yöntem yapmanın daha iyi olacağı görülüyor .

Yükleniciye neden bu şekilde yapıldığını sordum ve aldığım yanıt "İsterseniz değiştirebiliriz" oldu. Hangi gerçekten yardımcı olmadı.

Her neyse, böyle bir şeyi, herhangi bir programlama dilinde yapmak için bir neden var mı, yoksa Daily WTF'ye başka bir sunum mu?

Tamam, listeden aşağı doğru gidiyor:

Uzun zaman önce bir döngüdeki somutlaştırılmış nesnelerin genellikle kötü bir fikir olduğu öğretildi.

Kullandığım hiçbir dilde değil.

C'de değişkenlerinizi önceden bildirmek iyi bir fikirdir, ancak söylediklerinizden farklıdır. Nesneleri döngünün üstünde bildirir ve yeniden kullanırsanız biraz daha hızlı olabilir , ancak hızdaki bu artışın anlamsız olacağı birçok dil vardır (ve muhtemelen sizin için en iyi duruma getirmeyi yapan bazı derleyiciler var :)).

Genel olarak, bir döngü içindeki bir nesneye ihtiyacınız varsa, bir tane oluşturun.

inşaatçılar asgari iş yapmalı

Yapıcılar, bir nesnenin alanlarını başlatmalı ve nesneyi kullanıma hazır hale getirmek için gerekli diğer tüm başlatma işlemlerini yapmalıdır. Bu, genellikle, yapıcıların küçük olduğu anlamına gelir, ancak bunun önemli miktarda iş yapabileceği senaryolar vardır.

Böyle bir şeyi herhangi bir programlama dilinde yapmak için bir neden var mı, yoksa Daily WTF'ye başka bir başvuru mu oldu?

Daily WTF'ye bir gönderi. Verilmiş, kod ile yapabileceğiniz daha kötü şeyler var. Buradaki sorun, yazarın hangi sınıfların ne olduğu ve nasıl kullanılacağı konusunda geniş bir yanlış anlama olmasıdır. Özellikle, bu kodda yanlış olduğunu gördüğüm şey:

• Sınıfların yanlış kullanımı: Sınıf, temelde bir işlev gibi davranır. Bahsettiğiniz gibi, ya statik bir işlevle değiştirilmeli ya da işlev sadece onu çağıran sınıfta uygulanmalıdır. Ne yaptığına ve nerede kullanıldığına bağlı.
• Performans ek yükü: Dile bağlı olarak, bir nesneyi oluşturmak bir işlevi çağırmaktan daha yavaş olabilir.
• Genel karışıklık: Programcıya genellikle bu kodun nasıl kullanılacağı konusunda kafa karıştırıcıdır. Kullanıldığını görmeden, hiç kimse yazarın söz konusu kodu nasıl kullanacağını bilemezdi.

Benim için, yapıcıda çok iş yapan bir nesneyi almak biraz şaşırttı, bu yüzden sadece buna karşı öneriyorum (en az sürpriz prensibi).

İyi bir örnek girişimi :

Bu kullanımın bir kalıp önleyici olup olmadığından emin değilim, ancak C # 'da satırları boyunca olan bir kod gördüm (biraz örnek oluşturdum):

using (ImpersonationContext administrativeContext = new ImpersonationContext(ADMIN_USER))
{
    // Perform actions here under the administrator's security context
}
// We're back to "normal" privileges here

Bu durumda, ImpersonationContextsınıf bütün çalışmalarını kurucuda ve Dispose yönteminde yapar. usingC # geliştiricileri tarafından oldukça iyi anlaşılan C # ifadesinden yararlanır ve bu nedenle using, bir istisna oluşsa bile , ifadenin dışına çıktıktan sonra yapıcıda gerçekleşen kurulumun geri alınmasını garanti eder . Muhtemelen bunun için gördüğüm en iyi kullanımdır (örneğin, kurucuda "iş"), yine de "iyi" olarak değerlendireceğimden emin değilim. Bu durumda, oldukça kendini açıklayıcı, işlevsel ve özlü.

İyi ve benzer bir örüntü örneği, komut kalıbı olacaktır . Oradaki kurucudaki mantığı kesinlikle çalıştırmazsınız, ancak tüm sınıfın bir metot çağrısına eşdeğer olması (metodu çağırmak için gerekli parametreler dahil) anlamında benzerdir. Bu şekilde, yöntem çağırma bilgisi son derece yararlı olan daha sonraki kullanım için serileştirilebilir veya geçirilebilir. Belki de müteahhitleriniz benzer bir şey deniyorlardı, buna rağmen çok şüpheliyim.

Örneğinize ilişkin yorumlar:

Çok kesin bir anti-patern olduğunu söyleyebilirim. Hiçbir şey eklemez, beklenenin ötesine geçer ve kurucuda çok uzun işlem yapar (kurucudaki FTP? WTF, aslında insanların bu şekilde web hizmetleri çağırdığı biliniyor).

Teklifi bulmakta zorlanıyorum, ancak Grady Booch'un "Nesne Çözümleri" adlı kitabında C ++ 'a geçiş yapan bir C geliştiricileri takımı hakkında bir fıkra var. Görünüşe göre eğitim almışlardı ve yönetim tarafından kesinlikle "nesne yönelimli" şeyler yapmak zorunda oldukları söylendi. Neyin yanlış olduğunu bulmak için yola çıkan yazar, bir kod ölçüm aracı kullandı ve sınıf başına ortalama yöntem sayısının tam olarak 1 olduğunu ve "Do It" ifadesinin varyasyonları olduğunu buldu. Söylemeliyim ki, bu belirli bir problemle daha önce hiç karşılaşmadım, ancak görünüşe göre, gerçekten nasıl yapılacağını ve nedenini anlamadan, nesneye yönelik kod oluşturmaya zorlanan insanların bir belirtisi olabilir.

Hayır.

Tüm iş yapıcıda yapılırsa, nesneye asla ilk etapta ihtiyaç duyulmadığı anlamına gelir. Büyük olasılıkla, müteahhit sadece modülerlik için nesneyi kullanıyordu. Bu durumda, statik yöntemi olan somutlaştırılmamış bir sınıf, gereksiz nesne örnekleri oluşturmadan aynı yararı elde etmiş olur.

Bütün işi bir nesne kurucusunda yapmanın kabul edilebilir olduğu tek bir durum var. Nesnenin amacı, özellikle iş yapmaktan ziyade uzun vadeli benzersiz bir kimliği temsil etmektir. Böyle bir durumda, nesne anlamlı işler yapmaktan başka nedenlerle etrafta tutulur. Örneğin, bir singleton örneği.

Yapıcıdaki bir şeyi hesaplamak için çok fazla iş yapan birçok sınıf oluşturdum, ancak nesne değişmez, bu yüzden bu hesaplamanın sonuçlarını özellikler yoluyla kullanılabilir hale getiriyor ve sonra hiçbir şey yapmıyor. Bu eylemde normal değişmezlik.

Bence garip olan şey, yan etkileri olan kodları bir kurucuya koymak. Bir nesneyi inşa etmek ve özelliklere veya yöntemlere erişmeden onu fırlatmak garip görünüyor (ama en azından bu durumda başka bir şeyin olduğu oldukça açık).

İşlev, genel bir yönteme taşındıysa ve ardından enjekte edilen sınıfın bir örneğine sahipse, daha sonra for döngüsünün yöntemi tekrar tekrar çağırması daha iyi olurdu.

Bir nesnenin bütün eserini yapıcıda yapmak için bir sebep var mı?

Hayır.

• Bir yapıcının herhangi bir yan etkisi olmamalıdır.
  • Özel alan başlatma işleminden daha fazlası, yan etki olarak görülmelidir.
  • Yan etkileri olan bir kurucu, Tek Sorumluluk İlkesini (SRP) ihlal eder ve nesne yönelimli programlama (OOP) ruhuna aykırı hareket eder.
• Bir yapıcı hafif olmalı ve asla başarısız olmamalıdır.
  • Örneğin, bir yapıcı içinde bir try-catch bloğu gördüğümde her zaman titriyorum. Bir yapıcı istisnalar veya günlük hataları atmamalıdır.

Bir kişi bu yönergeleri makul bir şekilde sorgulayabilir ve “Ama bu kuralları izlemiyorum ve kodum iyi çalışıyor!” Diyebilir. Buna göre, "Olmazsaya dek, bu doğru olabilir" cevabını veririm.

• Bir yapıcının içindeki istisnalar ve hatalar çok beklenmeyen bir durumdur. Bunu yapmaları söylenmedikçe, gelecekteki programcıların bu yapıcı çağrılarını savunma koduyla çevrelemeye meyilli olmayacaklardır.
• Üretimde herhangi bir şey başarısız olursa, oluşturulan yığın izinin ayrıştırılması zor olabilir. Yığın izlemesinin tepesi yapıcı çağrısına işaret edebilir, ancak yapıcıda birçok şey olur ve başarısız olan gerçek LOC'ye işaret etmeyebilir.
  • Bunun olduğu birçok .NET yığını izini ayrıştırdım.

Bana öyle geliyor ki, bunu yapan kişi, birinci sınıf vatandaşlar olarak görevlerini yerine getirmesine izin vermeyen Java sınırlamasını aşmaya çalışıyordu. Ne zaman bir işlevi geçmek zorunda olursanız, bir sınıfın içine applybenzer veya benzeri bir yöntemle sarmanız gerekir .

Bu yüzden sadece bir kısayol kullandı ve doğrudan bir fonksiyon değişikliği olarak bir sınıf kullandı. Fonksiyonu ne zaman çalıştırmak istersen, sadece sınıfı başlat.

Bu kesinlikle iyi bir örnek değil, en azından bunu çözmeye çalışıyoruz çünkü Java'da işlevsel programlamaya benzer bir şey yapmanın en az ayrıntılı yolu olabilir.

Benim için başparmak kuralı, üye değişkenleri başlatmak dışında, kurucuda hiçbir şey yapmamaktır. Bunun ilk nedeni, genellikle uzun bir başlatma süreci, sınıfın yapması gerekenden daha fazlasını yaptığının bir göstergesidir ve başlangıç, sınıfın dışında bir yerde yapılması gerektiğini gösterir. İkinci sebep ise bu yolla sadece gerekli parametrelerin iletilmesidir, bu nedenle daha az bağlı kod yaratırsınız. Karmaşık başlatma işlemine sahip bir kurucu genellikle yalnızca başka bir nesneyi inşa etmek için kullanılan, ancak orijinal sınıf tarafından kullanılmayan parametrelere ihtiyaç duyar.

Burada gelgit karşısına çıkacağım - her şeyin bir sınıfta olması gereken dillerde ve statik bir sınıfa sahip olamıyorsanız, olması gereken yalıtılmış bir işlevsellik parçasının bulunduğu duruma girebilirsiniz. bir yere koy ve başka hiçbir şeye uymuyor. Seçimleriniz, ilgisiz çeşitli işlev parçalarını kapsayan bir yardımcı program sınıfı veya temelde yalnızca bu şeyi yapan bir sınıftır.

Bunun gibi bir bitiniz varsa, statik sınıfınız sizin kendi sınıfınızdır. Öyleyse, ya tüm işi yapan bir kurucunuz ya da tüm işi yapan tek bir işleve sahipsiniz. Yapıcıdaki her şeyi yapmanın avantajı, yalnızca bir kez gerçekleşmesi, yeniden kullanılması veya işlenmesi hakkında endişe etmeden özel alanları, özellikleri ve yöntemleri kullanmanıza izin vermesidir. Bir yapıcınız / yönteminiz varsa, parametrelerin tek bir yönteme geçirilmesine izin vermeye istekli olabilirsiniz, ancak özel iş parçacığı veya potansiyel iş parçacığı sorunları ortaya koyan özel alanlar kullanıyorsanız.

Yararlı bir sınıfla bile, çoğu insan iç içe statik sınıflar olduğunu düşünmez (ve dile bağlı olarak bu mümkün olmayabilir).

Temel olarak bu, davranışı dilin izin verdiği alanda, diğer dillerden olabildiğince yararlanmanıza izin verirken, sistemin geri kalanından izole etmenin nispeten anlaşılır bir yoludur.

Açıkçası, müteahhitinizin yaptığı gibi cevap verirdim, iki çağrıya dönüştürmek için küçük bir düzenleme yapıldı, biri diğerine önerecek kadar fazla değil. Hangi olumsuzluklar / avantajlar var, muhtemelen gerçeklerden daha varsayımsaldır, neden önemli olmadığı zaman kararı haklı çıkarmaya çalışın ve muhtemelen sadece varsayılan eylem olarak kararlaştırılmadı mı?

İşlevlerin ve sınıfların aynı şeyleri olduğu dillerde yaygın olan modeller vardır, Python gibi, birinin bir nesneyi temelde çok fazla yan etkisi olan veya çok sayıda adlandırılmış nesneyi döndüren işlev olarak kullanmak için.

Bu durumda, işin tamamı yapıcıda yapılamazsa, nesnenin kendisi sadece tek bir iş demeti etrafındaki bir sarıcı olduğundan ve bunu ayrı bir işleve doldurmak için iyi bir neden olmadığından, yığın. Gibi bir şey

var parser = XMLParser()
var x = parser.parse(string)
string a = x.LookupTag(s)

gerçekten daha iyi değil

 var x = ParsedXML(string)
 string a = x.LookupTag(s)

Doğrudan yan etkilerin doğrudan görülmesi yerine, daha iyi görünürlük sağlayan yan etkiyi zorlamak için nesneyi çağırabilirsiniz. Eğer bir nesne üzerinde kötü bir yan etkiye sahip olacaksam, bütün işimi yapabilirim ve sonra nesneyi geçebilirim. Kötü bir şekilde etkileyeceğim ve ona zararımı vereceğim. Nesneyi tanımlamak ve çağrıyı bu şekilde izole etmek, aynı anda birden fazla nesneyi bir işleve aktarmaktan daha açıktır.

x.UpdateView(v)

Nesne üzerindeki erişimciler aracılığıyla çoklu dönüş değerlerini yapabilirsiniz. Bütün iş bitti, ama ben bütün içeriği bağlamda istiyorum ve gerçekten fonksiyonuma çoklu referanslar iletmek istemiyorum.

var x = new ComputeStatistics(inputFile)
int max = x.MaxOptions;
int mean = x.AverageOption;
int sd = x.StandardDeviation;
int k = x.Kurtosis;
...

Yani ortak bir Python / C # programcısı olarak, bu bana çok garip gelmiyor.

Bir vaka, kurucu / yıkıcının tüm işi yaptığı yerde ortaya çıkar:

Kilitler. Normalde, kullanım ömrü boyunca hiçbir zaman bir kilitle etkileşime girmezsiniz. C # 'nin mimariyi kullanması, açıkça yıkıcıya atıfta bulunmadan bu gibi durumları ele almak için iyidir. Yine de bütün kilitler bu şekilde uygulanmıyor.

Ayrıca, bir çalışma zamanı kitaplığı hatasını düzeltmek için yalnızca yapıcı kodunun miktarını yazdım. (Aslında kodu düzeltmek başka sorunlara neden olabilirdi.) Yok edici yoktu, çünkü yamayı geri almaya gerek yoktu.

AndyBursh ile aynı fikirdeyim. Bazı bilgi eksikliği sorunu gibi görünüyor.

Ancak, yalnızca yapıcıda kod yazmanızı gerektiren (harita sınıfları oluştururken) NHibernate gibi çerçevelerden bahsetmek önemlidir. Ancak bu, çerçevenin bir kısıtlaması değil, tam da ihtiyacınız olan şey. Yansıma söz konusu olduğunda, yapıcı her zaman var olacak tek yöntemdir (her ne kadar özel olsa da) ve dinamik olarak bir sınıf yöntemini çağırmak zorunda kalırsanız bu yardımcı olabilir.

"Uzun zaman önce, bir döngü içindeki somutlaştırılmış nesnelerin genellikle kötü bir fikir olduğu öğretildi"

Evet, StringBuilder'a neden ihtiyacımız olduğunu hatırlıyor olabilirsiniz.

İki Java okulu var.

Oluşturucu, yeniden kullanılmamızı öğreten ilk kişi tarafından desteklendi (çünkü paylaşım = etkinlik için kimlik). Ancak, 2000 yılının başında Java'da nesne oluşturmanın çok ucuz (C ++ 'ın aksine) ve GC'nin çok verimli olduğunu ve yeniden kullanmanın değersiz olduğunu ve önemli olan tek şey programcının üretkenliği olduğunu okumaya başladım. Verimlilik için, modülerleştirme anlamına gelen yönetilebilir kod yazmalıdır (diğer bir deyişle, kapsamı daraltmak). Yani,

Bu kötü

byte[] array = new byte[kilos or megas]
for_loop:
  use(array)

bu iyi.

for_loop:
  byte[] array = new byte[kilos or megas]
  use(array)

Forum.java.sun olduğunda bu soruyu sordum ve insanlar diziyi mümkün olduğu kadar dar ilan etmeyi tercih edeceklerini kabul ettiler.

Modern java programcısı asla yeni bir sınıf ilan etmek veya bir nesne oluşturmaktan çekinmez. Bunu yapmaya teşvik edilir. Java, "her şeyin bir nesne olduğu" fikri ve ucuz bir yaratılış anlayışı ile bunu yapmak için bütün sebepleri veriyor.

Ayrıca, modern kurumsal programlama tarzı, bir eylem gerçekleştirmeniz gerektiğinde, bu basit eylemi gerçekleştirecek özel bir sınıf (hatta daha iyi bir çerçeve) yaratırsınız. İyi Java IDE'ler, burada yardımcı olur. Nefes alma gibi otomatik olarak tonlarca bok üretiyorlar.

Bu nedenle, nesnelerinizin Oluşturucu veya Fabrika modelinde olmadığını düşünüyorum. Kurucu tarafından doğrudan örnekler oluşturmak iyi olmaz. Her nesneniz için özel bir fabrika sınıfı tavsiye edilir.

Şimdi, fonksiyonel programlama devreye girdiğinde, nesnelerin oluşturulması daha da kolaylaşıyor. Bunu fark etmeden bile her adımda nefes alan nesneler yaratacaksınız. Bu nedenle, kodunuzun yeni dönemde daha "verimli" olacağını umuyorum

"Yapıcınızda hiçbir şey yapmayın. Bu yalnızca başlatma içindir"

Şahsen, kılavuzda bir sebep göremiyorum. Bunu başka bir yöntem olarak görüyorum. Faktoring kodu yalnızca paylaşabiliyorsanız gereklidir.