Alanlar ve yöntem bağımsız değişkenleri [kapalı]

Yeni bir sınıf yazmaya yeni başladım ve bana kesinlikle ihtiyaç duyulmayan bir çok yöntem argümanı eklediğim oldu. Bu, sınıfın genel yapılandırması veya bağımlılıkları olmaktan ziyade, bazı yöntem çağrılarına özgü sınıflarda durumdan kaçınmak için bir alışkanlığı izlemektedir.

Bunu yapmak, hiçbir argümanı bulunmayan birçok yöntemin bir, iki veya üç ile sonuçlandığı anlamına gelir.

Bu takas hakkında ne düşündüğünüz ve hangi durumda hangi yaklaşımı alacağınıza nasıl karar vereceğiniz konusunda fikirlerinizi duymak isterim?

Kod tanımlanırken kodun İngilizceden daha kolay anlaşılması nedeniyle, her iki varyantı da içeren küçük bir gist oluşturdum: https://gist.github.com/JeroenDeDauw/6525656

Örneğinizin harici olarak görünür tek yöntemi olduğundan updateTable, yöntem parametreleri yerine alanları kullanmanın iyi olduğunu düşünüyorum.

Bu daha genel bir sınıfın parçasıysa (örneğin TableTools), duruma ihtiyaç duyan yardımcı yöntemleri gizli bir iç sınıfa taşırdım.

Sözde kod örneği:

class TableTools {
    ...
    public void updateTable(currentTable, newTable) {
        TableUpdater u = new TableUpdater(schemaModifier, currentTable, newTable);
        u.removeRemovedFields();
        u.addAddedFields();
     }

     private class TableUpdater { ... }
}

Bu şekilde, yalnızca bir genel yöntem tarafından kullanılan alanlardan kaçınırsınız. Buna ek olarak, her updateTable çağrısının kendi TableUpdater ve dolayısıyla TableUpdater örnek değişkenlerinin bir kopyasını kullanması açısından kod güvenlidir.

Alanların kullanılması, bu alanları kullanan yöntemler için çoklu iş parçacığının kullanılabilir olmasını sağlar.

Bunun gibi alanları kullanmak, küreselleri yeniden kullanılabilirlik ve sürdürülebilirlik açısından kullanmaktan biraz daha iyidir, burada kilit nokta, karmaşık kurulumların hangi yöntemlerin kullanıldığına ve / veya hangi alanların işe yaradığına ilişkin dikkatli ve güncel belgelere ihtiyaç duymasıdır; argüman kullanırken yapmanız gerekmeyen bir şey.

Layman'ın sözleriyle:

• yöntemlerin olabildiğince az argümanı olmalıdır (Martin Temiz Kod)
• nesnelerin özelliklerinden biri, bir duruma sahip olmaları (ve yapmaları) gerektiğidir
• nesnenin durumunda çalışmayan, yani her şeyi parametre olarak alan statik olmayan yöntemler
• yapışmayan yöntemler de statik hale getirilebilir ve bir faydalı sınıfta gruplandırılabilir

Yine, alçakgönüllü görüşüme göre, yapışmayan yöntemler, etki alanı adı olan bir sınıfa değil, bir fayda sınıfına aittir.

Mevcut durumda alanları kullanmayın! Nesneyi aynı anda kullanan iki "iş parçacığı" birbirini ciddi şekilde karıştırır. Onlar da gerçek, ayrı bir konu olmak zorunda değiller (bu yüzden tırnak işaretleri). Nesneyi bir tablo için ayarladıysanız, başka bir tablo için kullanan bir yöntemi çağırın, sonra orijinal kurulumu kullanmaya çalışın, bir sorununuz var. Şu an için parametrelerle sopa.

Ne istiyorsun burada yapılacak tek bir vakada kullanılan yeni bir güncelleyici sınıf oluşturmaktır. Orijinal sınıf, gerektiğinde örnek oluşturma yöntemine sahip olabilir. Yeni sınıfın alanları olurdu. Her iki dünyanın da en iyisine sahipsiniz. Bazen sadece parametrelere sadık kalmak daha kolaydır, ancak örneğinizde zaten ayrı bir sınıfın daha iyi olacağı yere ulaşıyorsunuz.

Bence, seçimin gördüğünüz gibi gerçek duruma göre olması gerekiyor. Bir öğe bir örneğe aitse, onun alanı olarak görülmelidir. Öğe örneğe harici ise, bir yöntem parametresi olarak geçirilmelidir.

Bu durumda, yazmanın etkinliği (fark yine de önemsizdir) veya (Tanrı kurtarır!) Değil, kodun anlaşılabilirliği ve doğallığı ile yönlendirilmeliyiz.

Benim düşünceme göre , bir şeye bir şey yapan bir kod yazıyorsanız , onlara ne yapması gerektiğini tanımlayan parametreler almalı ve adı, ona ne yaptığını mümkün olduğunca tanımlamalıdır.

Bir şey üzerinde gerçekleştirilecek bir eylemi paketleyen kod yazıyorsanız , bir nesnede gerçekleştirilmesi gereken şeyleri sarmalı ve bunları bir şey yapan şeyinize iletmelisiniz .

Bu eylem , daha sonra belki de daha sonraki bir tarihte kuyruğa alarak gerçekleştirebileceğiniz veya hatta herhangi bir nedenle yapmamaya karar verebileceğiniz ilk yöntemlere yapılan çağrıların bir tür meta açıklaması haline gelir.

Yani sorunuz şu anlama geliyor bir Eylem veya İşlev mi? Bir Eylem ertelenebilir veya iptal edilebilir ve bu nedenle üzerinde etkili olduğu eylemi kapsamalıdır. Bir Fonksiyon hemen gerçekleşir, bu yüzden parametrelerini en üst düzeyde korumaya gerek yoktur.

Bir İşlevi geri alamaz ve Eylem yapabilirsiniz .