Baru-baru ini saya menyarankan metode chaining diimplementasikan untuk kelas tertentu dalam proyek tertentu sehingga keterbacaan kode dapat ditingkatkan. Saya mendapat "antarmuka yang lancar tidak seharusnya diimplementasikan hanya untuk kenyamanan, tetapi untuk semantik" menjawab dan saran saya ditembak jatuh. Saya menjawab bahwa saya tidak menyarankan antarmuka yang lancar tetapi metode chaining itu sendiri (keduanya dapat dikacaukan satu sama lain, baca di bawah) untuk meningkatkan keterbacaan dan kenyamanan pengkodean, saran itu ditembak jatuh lagi.

Bagaimanapun, ini membuat saya berpikir bahwa mungkin saya dapat mengalami praktik buruk dengan selalu mengembalikan "ini" dalam metode yang tidak seharusnya mengembalikan apa pun (misalnya seter).

Pertanyaan saya adalah: dapatkah menerapkan konvensi sebelumnya dianggap sebagai praktik atau penyalahgunaan yang buruk ?, mengapa? Saya tidak berpikir ada kekurangan kinerja, atau ada?

Tidak

Seperti yang ditunjukkan oleh Kent Beck , kode dibaca jauh lebih sering daripada yang tertulis.

Jika metode chaining membuat kode Anda lebih mudah dibaca, maka gunakan metode chaining.

Ya, ada kekurangannya

Kode yang mudah dibaca itu baik, tetapi juga berhati-hatilah dengan apa yang dikomunikasikan kode juga. Ketika metode objek selalu mengembalikan objek, itu mengkomunikasikan beberapa hal:

1. Saya memerlukan konfigurasi lanjutan yang belum tentu jelas dengan urutan hal mana yang harus diatur atau dikonfigurasi
2. Setiap panggilan metode selanjutnya dibangun berdasarkan yang terakhir

Kasing Penggunaan yang Valid: Kueri Basis Data Ad Hoc

Pustaka kelas ada di sebagian besar setiap bahasa yang memungkinkan Anda untuk query database tanpa menggunakan SQL kode keras. Ambil Entity Framework untuk .NET sebagai contoh:

DBContext db = new DBContext();
List<Post> posts = db.Posts
    .Where(post => post.Title.Contains("Test"))
    .OrderBy(post => post.DateCreated)
    .ToList();

Ini adalah antarmuka yang lancar di mana setiap panggilan metode selanjutnya dibangun di atas yang sebelumnya. Membaca panggilan ini secara logis masuk akal dalam konteks permintaan basis data.

Case Penggunaan Tidak Valid: Gula Sintaksis Untuk Mengatur Properti

Sekarang mari kita gunakan pola yang sama dengan Postkelas:

public class Post
{
    public string Title { get; set; }
    public DateTime DateCreated { get; set; }
    public string Body { get; set; }

    public Post SetTitle(string title)
    {
        Title = title;

        return this;
    }

    public Post SetDateCreated(DateTime created)
    {
        DateCreated = created;

        return this;
    }

    public Post SetBody(string body)
    {
        Body = body;

        return this;
    }
}

Sekarang mari kita lihat bagaimana Anda akan menggunakan kelas ini:

Post post = new Post()
    .SetTitle("Test")
    .SetDateCreated(DateTime.Now)
    .SetBody("Just a test");

Ketika saya melihat kode ini, saya langsung menanyakan pertanyaan ini: "Setelah menelepon SetBody, apakah ini meminta basis data? Apakah saya perlu memanggil metode lain untuk mengatakan 'Saya sudah selesai?'"

Apa yang metode panggilan berantai berkomunikasi ke kode menggunakan Postkelas?

1. Saya memiliki pengaturan yang rumit
2. Setiap pemanggilan metode dibangun dari yang sebelumnya

Apakah ini benar ? Tidak. PostKelas tidak memiliki pengaturan yang rumit. Pengaturan judul, tanggal dibuat dan tubuh tidak membangun satu sama lain menuju tujuan akhir yang lebih rumit. Anda telah menumbuk pasak persegi menjadi lubang bundar.

Kekurangan dari metode self-referential chain adalah bahwa Anda berkomunikasi bahwa beberapa panggilan metode diperlukan untuk melakukan sesuatu, dan bahwa setiap panggilan dibangun dari yang terakhir. Jika ini tidak benar, maka metode chaining bisa mengkomunikasikan hal yang salah kepada programmer lain.

Ketika rekan kerja Anda berkata:

Antarmuka yang lancar tidak harus diimplementasikan hanya untuk kenyamanan, tetapi untuk semantik

Mereka benar sekali. Antarmuka yang lancar, atau metode chaining, mengkomunikasikan sesuatu di dalam dan dari dirinya sendiri yang mungkin tidak benar.

Kelemahan utama adalah hilangnya kejelasan. Contohnya:

x.foo();
x.bar();
x.baz();

Karena tidak satu pun dari pernyataan tersebut yang mengembalikan nilai (atau jika benar, itu diabaikan), mereka hanya dapat berguna jika menghasilkan efek samping. Bandingkan itu dengan:

x.foo()
 .bar()
 .baz();

Pertama, tidak jelas itu bardan bazberoperasi pada objek dengan tipe yang sama x, kecuali jika Anda tahu fakta bahwa xkelas adalah satu-satunya kelas dengan metode tersebut. Bahkan jika itu masalahnya, tidak jelas metode beroperasi x, atau objek baru.

Menyoroti bagian-bagian kode yang memiliki efek samping berguna, karena Anda perlu melacak efek samping tersebut untuk alasan tentang program ini. Anda harus mempertimbangkan potensi hilangnya kejelasan terhadap potensi keuntungan dalam kemudahan menulis kode, tetapi juga mempertimbangkan bahwa kode lebih banyak dibaca daripada yang tertulis.

Pertimbangkan semua elemen gaya bahasa pemrograman (sebagai lawan dari bahasa mesin pengkodean tangan), dan itu melemahkan argumen "semantik bukan kenyamanan".

Banyak hal yang kami lakukan sebagai insinyur memberikan kenyamanan di semantik.