Apakah 'Hukum Demeter' berlaku untuk tanda tangan metode publik / API?


10

Mengingat bahwa perubahan pada tanda tangan API / metode publik harus minimal untuk mencegah pemecahan kode klien yang menggunakan metode ini, saya bertanya-tanya apakah Hukum Demeter kurang berlaku untuk ini.

Contoh sederhana:

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

Perhatikan bahwa metode debit melewati objek Transaksi daripada hanya jumlah ganda ('Hukum Demeter', seperti yang saya mengerti, akan mengatakan untuk hanya meneruskan informasi yang diperlukan, dalam hal ini hanya jumlah, bukan objek Transaksi ... ). Alasan di balik ini, adalah karena metode di masa depan mungkin memerlukan beberapa properti Transaksi selain jumlah. Dari apa yang saya mengerti, ini akan mencegah melanggar metode tanda tangan dengan menambahkan parameter baru di masa depan.

Apakah ini menjadikannya pilihan yang masuk akal? Atau apakah saya melewatkan sesuatu?

Jawaban:


3

Tetapi ini tidak melanggar Hukum Demeter.

Lebih formal, Hukum Demeter untuk fungsi mensyaratkan bahwa metode M dari objek O hanya dapat memanggil metode dari jenis objek berikut:

  • O sendiri
  • Parameter M.
  • benda apa pun yang dibuat / dipakai dalam M
  • Objek komponen langsung O
  • variabel global, dapat diakses oleh O, dalam lingkup M

Wikipedia: Hukum Demeter

Transaksi adalah argumen untuk metode debit, jadi menelepon t.getAmount () tidak masalah.

Sunting: Salah membaca itu, Anda mengatakan bahwa LoD akan meminta Anda meneruskan jumlah transaksi, bukan objek Transaksi. Jika itu masalahnya maka ya, saya pikir ini adalah tempat yang baik untuk memecahkannya, mengetahui Anda akan membutuhkan lebih banyak dari objek Transaksi di masa depan. Juga, merangkum primitif dalam objek tingkat domain adalah praktik pemrograman lain yang baik.

Sunting 2: Setelah membaca mungkin perlu lebih banyak di masa depan, orang juga bisa melihat ini sebagai pelapisan emas yang tidak perlu. Memberikan metode yang membutuhkan dua kali lipat sekarang (atau lebih baik kelas Uang) sudah cukup. Jika Anda benar-benar membutuhkan argumen Transaksi nanti, tidak buruk untuk menyediakan tanda tangan kedua yang mengambil Transaksi, tetapi terus mendukung tanda tangan asli. Ini tidak seperti Anda akan menerapkan dua metode, yang satu akan memanggil yang lain.


Terima kasih atas masukan Anda. Saya setuju tentang enkapsulasi primitif dalam objek domain. Namun, hanya poin Anda di Edit 2, Anda mengatakan itu tidak berbahaya untuk menambahkan tanda tangan ke-2 yang baru, tetapi itu berarti perubahan kode ke kode klien yang sekarang harus melewati 2 parameter, bukan satu. Poin ke-2 itu, saya agak ragu untuk menyetujui ...
Carlos Jaime C. De Leon

Sunting 2 adalah subyektif, saya setuju.
Sean

0

Jika Anda berencana memperluas Accountkelas di masa depan, saya akan mengatakan ini adalah situasi di mana membuat Transactionobjek lebih umum akan menjadi pelengkungan yang baik dari aturan-aturan Hukum.

Sebagai contoh:

public class Amount {

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

public abstract class Transaction {

    public String getType();

}

Saya pikir saya agak menyimpang dari pertanyaan awal, tetapi poin saya adalah bahwa sementara Anda mungkin khawatir bahwa Anda menyimpang dari Hukum Demeter, keuntungan melakukan hal itu lebih besar daripada yang negatif.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.