Getters'da Ne Kadar Mantık

İş arkadaşlarım bana alıcılarda ve ayarlayıcılarda mümkün olduğunca az mantık olması gerektiğini söyledi.

Bununla birlikte, kullanıcıları / programcıları uygulama detaylarından korumak için alıcılar ve ayarlayıcılarda birçok şeyin gizlenebileceğine inanıyorum.

Yaptıklarımın bir örneği:

public List<Stuff> getStuff()
{
   if (stuff == null || cacheInvalid())
   {
       stuff = getStuffFromDatabase();
   }
   return stuff;
}

İşin bana bir şeyler yapmamı söylediğinin bir örneği (Bob Amca'dan 'Temiz Kod' diyorlar):

public List<Stuff> getStuff()
{
    return stuff;
}

public void loadStuff()
{
    stuff = getStuffFromDatabase();
}

Bir ayarlayıcı / alıcıda ne kadar mantık uygundur? Veri saklamanın ihlali dışında boş alıcı ve ayarlayıcıların kullanımı nedir?

İşin sana bir şeyler yapmanı söyleme şekli topal.

Genel bir kural olarak, işleri yapma yöntemim şu şekildedir: eğer eşyaları almak hesaplamalı olarak ucuzsa, (ya da çoğu şans önbellekte bulunursa), o zaman getStuff () stiliniz iyi olur. Maddelerin elde edilmesinin hesaplama açısından pahalı olduğu biliniyorsa, bu yüzden pahalı olması, arayüzde maliyetinin reklamını yapmak için çok gerekliyse, o zaman bunu getStuff () olarak adlandırmazdım, belirtmek için onu hesaplamakStuff () veya benzeri bir şey olarak adlandırırım. yapılacak bazı işler olacak.

Her iki durumda da, işin size bir şeyler yapmasını söyleme şekli topaldır, çünkü loadStuff () önceden çağrılmadıysa, getStuff () patlar, bu nedenle işlem sırası karmaşıklığını getirerek arabiriminizi karmaşıklaştırmanızı isterler. ona. Operasyon sırası, aklıma gelen en kötü karmaşıklıktır.

Alıcıların mantığı tamamen iyi.

Ancak bir veritabanından veri almak, "mantık" dan çok daha fazlasıdır. Pek çok şeyin yanlış gidebileceği ve deterministik olmayan bir şekilde çok pahalı operasyonlar dizisi içerir . Bunu bir alıcıda dolaylı olarak yapmaktan çekinirim.

Öte yandan, ORM'lerin çoğu koleksiyonların tembel yüklenmesini desteklemektedir, bu temelde tam olarak ne yaptığınızdır.

'Temiz Kod'a göre, mümkün olduğu kadar bölünmüş olması gerektiğini düşünüyorum.

public List<Stuff> getStuff() {
   if (hasStuff()) {
       return stuff;
   }
   loadStuff();
   return stuff;
}

private boolean hasStuff() {
    if (stuff == null) {
       return false;
    }
    if (cacheInvalid()) {
       return false;        
    }
    return true;
} 

private void loadStuff() {
    stuff = getStuffFromDatabase();
}

Elbette, yazdığınız güzel biçimin, bir bakışta herkesin anlayabileceği bir kod bölümü ile doğru olanı yapması koşuluyla, bu tamamen saçmalıktır:

public List<Stuff> getStuff() {
   if (stuff == null || cacheInvalid()) {
       stuff = getStuffFromDatabase();
   }
   return stuff;
}

Eşyaların kaputun altına nasıl girildiği, arayanın baş ağrısı olmamalı ve özellikle bazı şeyleri keyfi bir şekilde "doğru sırayla" çağırmayı hatırlamak, arayanın baş ağrısı olmamalıdır.

Bana alıcılarda ve ayarlayıcılarda mümkün olduğunca az mantık olması gerektiğini söylediler.

Sınıfın ihtiyaçlarını karşılamak için gereken kadar mantık olması gerekiyor. Kişisel tercihim mümkün olduğunca az, ancak kodu korurken, genellikle orijinal alıcıyı mevcut alıcılarla / ayarlayıcılarla bırakmanız gerekir, ancak yeni iş mantığını düzeltmek için bunlara çok fazla mantık koymanız gerekir (örneğin, "müşteriler" "911 sonrası bir ortamda bulunan alıcı," müşterinizi tanıyın "ve OFAC düzenlemeleri ile bir araya gelmeli , bazı ülkelerden gelen müşterilerin (Küba veya İran gibi) görünmesini yasaklayan bir şirket politikasıyla bir araya geldi.

Örnekte, ben de seninkini tercih ve "amca bob" sürüm aramaya hatırlamak kullanıcılar / bakıcılarına gerektirdiğinden "amca bob" örnek sevmediğim loadStuff()onlar aramadan önce getStuff()- bu felakete davetiye olup olmadığını sürdürücüler unutuyor herhangi bir tek bir (veya daha da kötüsü, asla bilmiyordum). Son on yılda çalıştığım yerlerin çoğu hala on yıldan daha eski olan kodları kullanıyor, bu nedenle bakım kolaylığı göz önünde bulundurulması gereken önemli bir faktör.

Haklısın, meslektaşların yanlış.

Bir get metodunun yapması gereken veya yapmaması gerekenler hakkında herkesin kurallarını unutun. Bir sınıf bir şeyin soyutlamasını sunmalıdır. Sınıfınız okunabilir stuff. Java'da, özellikleri okumak için 'get' yöntemlerini kullanmak gelenekseldir. Milyarlarca çizgi çerçevenin, stuffarayarak okunmasını bekledikleri yazılmıştır getStuff. İşlevinize fetchStuffveya başka bir şeye ad verirseniz getStuff, sınıfınız tüm bu çerçevelerle uyumsuz olacaktır.

Onları Hazırda Beklet'e yönlendirebilir, burada 'getStuff ()' çok karmaşık şeyler yapabilir ve başarısızlığa RuntimeException'ı atar.

Bunun gibi sesler, işlev adlarını nasıl kontrol etmeyi tercih ettiğinizden etkilenebilecek, uygulamalara karşı biraz daha saf olabilir. Uygulanan bakış açısıyla, daha çok görmek isterdim:

List<String> names = clientRoster.getNames();
List<String> emails = clientRoster.getEmails();

Aksine:

myObject.load();
List<String> names = clientRoster.getNames();
List<String> emails = clientRoster.getEmails();

Veya daha da kötüsü:

myObject.loadNames();
List<String> names = clientRoster.getNames();
myOjbect.loadEmails();
List<String> emails = clientRoster.getEmails();

Bu sadece diğer kodları daha fazla gereksiz hale getirme ve okumayı zorlaştırmaya meyillidir, çünkü tüm benzer çağrılara girmeye başlamanız gerekir. Ek olarak, yükleyici işlevlerini veya benzerlerini çağırmak, birlikte çalıştığınız nesnenin uygulama ayrıntılarından artık soyutlanmamak için OOP'yi kullanmanın tüm amacını ortadan kaldırır. Bir clientRosternesneniz varsa, nasıl getNamesçalıştığını umursamanız gerekmiyor , tıpkı bir aramanız loadNamesgerektiği gibi, müşterilerin isimlerini getNamessize verdiğini bilmelisiniz List<String>.

Bu nedenle, mesele anlamsallık ve verinin elde edilmesi için en iyi isim hakkında daha çok şey gibi geliyor. Eğer şirket (ve diğerleri) getve setön ekiyle ilgili bir sorun yaşarsa, retrieveNamesbunun yerine işlevi çağırmak ister misiniz ? Neler olduğunu söylüyor, ancak işlemin bir getyöntemden beklenebileceği gibi anında olacağı anlamına gelmiyor .

Bir erişimci yöntemindeki mantık açısından, değişkenle birlikte meydana gelen yalnızca nominal etkileşimle, anında olduğu gibi, minimumda tutunuz. Bununla birlikte, bu genellikle yalnızca basit tipler için de geçerlidir, karmaşık veri tipleri (yani List) bir mülkte düzgün bir şekilde kapsüllenmesi daha zor buluyorum ve genellikle katı bir mutasyona ve erişimciye karşı onlarla etkileşime geçmek için başka yöntemler kullanıyorum.

Bir alıcıyı çağırmak, bir alanı okumakla aynı davranışı sergilemelidir:

• Değeri almak ucuz olmalı
• Setter ile bir değer ayarladıysanız ve ardından alıcı ile okuduysanız, değer aynı olmalıdır
• Değeri almanın hiçbir yan etkisi olmamalıdır
• Bir istisna atmamalı

Kendi değerini hesaplamak için diğer özellikleri ve yöntemleri çağıran bir alıcı da bir bağımlılık anlamına gelir. Örneğin, mülkünüzün kendisini hesaplayabilmesi ve bunu yapmak için başka bir üye kurulmasını gerektiriyorsa, mülkünüze tüm üyelerin zorunlu olarak ayarlanmadığı durumlarda başlatma kodunda erişilirse, yanlışlıkla boş referanslar için endişelenmeniz gerekir.

Bu, 'alıcıdaki mülkleri destekleme alanı olmayan başka bir üyeye asla erişmemek' anlamına gelmez, bu yalnızca nesnenin gereken durumunun ne olduğunu ima ettiğinize dikkat etmek anlamına gelir ve bu beklediğiniz bağlamla eşleşiyorsa erişilecek bu özelliğe.

Ancak, verdiğiniz iki somut örnekte, birini diğerinden seçmemin nedeni tamamen farklı. Alıcınız ilk erişimde başlatılır, örneğin, Tembel Başlatma . İkinci örneğin bir önceki noktada başlatıldığı varsayılmaktadır, örneğin, Açık Başlatma .

Tam olarak başlatıldığında, önemli olabilir veya olmayabilir.

Örneğin, çok çok yavaş olabilir ve kullanıcının, erişimi ilk tetiklediğinde beklenmedik şekilde hıçkırmak yerine performanstan ziyade, kullanıcının bir gecikme beklediği bir yükleme adımı sırasında yapılması gerekir (örneğin, kullanıcı sağ tıklar, bağlam menüsü görünür, kullanıcı zaten sağ tıkladım).

Ayrıca, bazen, önbelleğe alınmış özellik değerini etkileyebilecek / kirletebilecek her şeyin gerçekleştiği uygulamada bariz bir nokta vardır. Daha sonra bağımlılıkların hiçbirinin değişmediğini ve istisnalar atamadığını bile doğrulayabilirsiniz. Bu durumda, kodlama işlemini daha karmaşık ve zihinsel olarak takip etmeyi zorlaştırmaktan kaçınmak için, özellikle hesaplanması pahalı olmasa da, bu noktada değeri önbelleğe almak mantıklıdır.

Bununla birlikte, Lazy Initialization, birçok başka durumda çok anlamlı. Bu nedenle, sık sık programlamada bir kurala indirgemenin zorluğunu programlamada olduğu gibi, somut koda gelir.

Sadece, @NikeNakis'in dediği gibi yapın ... Eğer sadece eşyaları alırsanız sorun değil ... Başka bir şey yaparsanız, işi yapan ve herkese açık hale getiren yeni bir fonksiyon yaratın.

Mülkünüz / işleviniz yalnızca adının yazdığı şeyi yapıyorsa, geriye kalan komplikasyon için fazla yer kalmaz. Uyum IMO anahtarıdır

Şahsen, Stuff öğesinin yapıcısındaki bir parametre aracılığıyla gereksinimini ortaya koyardım ve hangi sınıfın hangi nesneyi somutlaştırdığını, nereden geleceğini bulmak için çalışmasını sağlardım. İşler boşsa boş döndürmelidir. OP'nin orijinali gibi akıllı çözümler denememeyi tercih ederim, çünkü uygulamanızın içindeki böcekleri gizlemenin kolay bir yolu çünkü bir şey kırıldığında neyin yanlış olabileceği belli değil.

Burada sadece "uygunluk" yerine daha önemli konular var ve kararınızı bunlara dayandırmalısınız . Esas olarak, buradaki büyük karar, insanları önbelleği atlatmak için izinsiz bırakmak isteyip istemediğinizdir.

1. İlk önce, kodunuzu yeniden düzenlemenin bir yolu olup olmadığını düşünün, böylece tüm gerekli yük çağrıları ve önbellek yönetimi yapıcı / başlatıcıda yapılır. Bu mümkünse, değişmeyen kısmı 2. kısımdaki basit alıcıya yapmanıza izin veren bir sınıf oluşturabilirsiniz. 1. kısımdaki karmaşık alıcıların güvenliği ile. (Bir kazan-kazan senaryosu)

2. Eğer böyle bir sınıf oluşturamazsanız, bir takas durumunuz olup olmadığına karar verin ve tüketicinin önbellek kontrol kodunu atlamasına izin vermek isteyip istemediğinize karar vermeniz gerekir.

   1. Tüketicinin önbellek kontrolünü asla atlamaması ve performans cezalarına aldırış etmemeniz önemliyse, o zaman çeki alıcının içinde birleştirin ve tüketicinin yanlış şeyi yapmasını imkansız hale getirin.

   2. Önbellek kontrolünü atlamak uygunsa ya da alıcıdaki O (1) performansı garantilemeniz çok önemliyse, ayrı çağrılar kullanın.

Daha önce de belirtmiş olabileceğiniz gibi, “temiz kod” un “her şeyi küçük fonksiyonlara bölme” felsefesinin büyük bir hayranı değilim. Herhangi bir sırayla çağrılabilen bir grup ortogonal fonksiyonunuz varsa, bunları ayırmak size düşük maliyetle daha etkileyici bir güç verecektir. Bununla birlikte, işlevleriniz düzen bağımlılıklarına sahipse (veya yalnızca belirli bir düzende gerçekten faydalıysa), bunları bölmek yalnızca çok az fayda eklerken yanlış şeyler yapmanın yollarını artırır.

Kanımca, Getters’in içinde çok fazla mantık olmamalı. Yan etkileri olmamalıdır ve onlardan asla bir istisna almamalısınız. Tabii ki ne yaptığını bilmiyorsun. Alıcılarımın çoğunda içlerinde mantık yok ve sadece bir tarlaya git. Ancak bunun kayda değer istisnası, kullanımı mümkün olduğu kadar basit olması gereken genel bir API ile oldu. Bu yüzden, başka bir alıcı aranmazsa başarısız olabilecek bir alıcı buldum. Çözüm? var throwaway=MyGetter;Ona bağlı alıcıda olduğu gibi bir kod satırı . Gurur duymuyorum ama hala daha temiz bir yol göremiyorum

Bu tembel yükleme ile önbellekten bir okuma gibi görünüyor. Diğerlerinin de belirttiği gibi, kontrol ve yükleme diğer yöntemlere ait olabilir. Yüklemenin senkronize edilmesi gerekebilir, böylece aynı anda yirmi adet iş parçacığı yüklenmez.

getCachedStuff()Sabit bir yürütme süresine sahip olmayacağından alıcı için bir ad kullanmak uygun olabilir .

Rutinin nasıl cacheInvalid()çalıştığına bağlı olarak , null kontrolü gerekli olmayabilir. stuffVeritabanından doldurulmadığı sürece önbelleğin geçerli olmasını beklemem .

Liste döndüren alıcılarda görmeyi beklediğim ana mantık, listenin değiştirilemez olduğundan emin olmak için mantıktır. Her iki örneğinizin yanında olduğu gibi, potansiyel olarak kapsülleme kırılır.

gibi bir şey:

public List<Stuff> getStuff()
{
    return Collections.unmodifiableList(stuff);
}

Alıcıda önbelleklemeye gelince, bunun iyi olacağını düşünüyorum ancak önbellek oluşturma işlemi önemli bir zaman aldıysa önbellek mantığını kaldırmak için cazip gelebilirim. yani bağlıdır.

Tam kullanım durumuna bağlı olarak, önbelleğimi ayrı bir sınıfa ayırmayı seviyorum. Bir StuffGetterarayüz yapın, StuffComputerhesaplamaları yapın ve cache'ye StuffCachererişmekten veya çağrıları sarmalanmasına yönlendirmekten sorumlu olan bir nesnenin içine sarın StuffComputer.

interface StuffGetter {
     public List<Stuff> getStuff();
}

class StuffComputer implements StuffGetter {
     public List<Stuff> getStuff() {
         getStuffFromDatabase()
     }
}

class StuffCacher implements StuffGetter {
     private stuffComputer; // DI this
     private Cache<List<Stuff>> cache = new Cache<>();

     public List<Stuff> getStuff() {
         if cache.hasStuff() {
             return cache.getStuff();
         }

         List<Stuffs> stuffs = stuffComputer.getStuff();
         cache.store(stuffs);
         return stuffs;
     }
}

Bu tasarım, kolayca önbellek eklemenizi, önbelleği kaldırmanızı, altta yatan türev mantığını değiştirmenizi sağlar (örneğin, sahte veriyi geri döndüren DB'ye erişme), vb.

IMHO, bir tasarım sözleşmeli kullanırsanız çok basittir. Alıcınızın neyi sağlaması gerektiğine karar verin ve buna göre sadece kod verin (basit kod veya bir yere dahil olabilecek veya yetki verilmiş olan bazı karmaşık mantık).