'Demeter Yasası' genel / API yöntemi imzalarına uygulanabilir mi?

Bu yöntemleri kullanan istemci kodlarının kırılmasını önlemek için API / genel yöntem imzasındaki değişikliklerin minimum düzeyde olması gerektiği göz önüne alındığında , Demeter Yasası'nın bunlara daha az uygulanabilir olup olmadığını merak ediyordum .

Basit bir örnek:

class Account() {
   double balance;
   public void debit(Transaction t) {
      balance -= t.getAmount();
   }
}

Borçlandırma yönteminin sadece iki tutardan ziyade İşlem nesnesini geçtiğine dikkat edin ('Demeter Yasası', anladığım kadarıyla, gerekli bilgileri, bu durumda sadece İşlem nesnesini değil, yalnızca tutarı geçmeyi söyleyebilir ... ). Bunun ardında yatan neden, gelecekteki yöntemin miktar dışında başka bazı İşlem özellikleri gerektirebilmesidir. Anladığım kadarıyla, bu, gelecekte yeni bir parametre ekleyerek yöntem imzasının kırılmasını önleyecektir.

Bu onu mantıklı bir seçim yapıyor mu? Yoksa bir şey mi kaçırıyorum?

Ama bu Demeter Yasasını çiğnemez.

Daha resmi olarak, İşlevler için Demeter Yasası, bir O nesnesinin bir M yönteminin yalnızca aşağıdaki nesne türlerinin yöntemlerini çağırmasını gerektirir:

• O'nun kendisi
• M parametreleri
• M içinde yaratılan / örneklenen nesneler
• O'nun doğrudan bileşen nesneleri
• M kapsamında O tarafından erişilebilen küresel bir değişken

Vikipedi: Demeter Yasası

İşlem, borçlandırma yönteminin bir bağımsız değişkenidir, bu nedenle t.getAmount () yönteminin çağrılması iyidir.

Düzenleme: Yanlış, LoD size bir İşlem nesnesi değil, işlem miktarını geçmek istiyorsunuz söylüyorsun. Bu durumda evetse, gelecekte işlem nesnesinden daha fazlasına ihtiyacınız olacağını bilerek, burası kırmak için iyi bir yer olduğunu düşünüyorum. Ayrıca, etki alanı düzeyindeki nesnelerdeki ilkelleri kapsüllemek de iyi bir programlama uygulamasıdır.

Düzenleme 2: okumak zorunda kudreti daha ileride ihtiyacı, bir de gereksiz altın kaplama olarak algılamak mümkün. Şimdi iki katı alan bir yöntem (veya daha iyi bir Money sınıfı) sağlamak yeterlidir. Daha sonra bir İşlem bağımsız değişkenine ihtiyacınız varsa, bir İşlem alarak ikinci bir imza sağlamak felaket değildir, ancak orijinal imzayı desteklemeye devam edin. İki yöntem uygulayacak gibi görünmüyorsunuz, biri diğerini çağırıyor.

AccountGelecekte sınıfı genişletmeyi planlıyorsanız, bunun Transactionnesneyi daha genel bir amaç haline getirmenin Kanun kurallarının iyi bir şekilde büküleceği bir durum olduğunu söyleyebilirim .

Örneğin:

public class Amount {

    public void process( Transaction t ) {
        ....
    }
}

public abstract class Transaction {

    public String getType();

}

Sanırım asıl sorudan uzaklaşıyorum, ama benim açımdan, Demeter Yasası'ndan saptığınızdan endişelenmenize rağmen, bunu yapmanın avantajları olumsuzluklardan daha ağır basmaktadır.