Dikatakan oleh beberapa orang bahwa jika Anda mengambil prinsip-prinsip SOLID secara ekstrem, Anda berakhir pada pemrograman fungsional . Saya setuju dengan artikel ini, tetapi saya berpikir bahwa beberapa semantik hilang dalam transisi dari antarmuka / objek ke fungsi / penutupan, dan saya ingin tahu bagaimana Pemrograman Fungsional dapat mengurangi kerugian.
Dari artikel:
Selain itu, jika Anda menerapkan Prinsip Segregasi Antarmuka (ISP) dengan teliti, Anda akan memahami bahwa Anda harus memilih Antarmuka Peran daripada Antarmuka Header.
Jika Anda terus mengarahkan desain ke antarmuka yang lebih kecil dan lebih kecil, pada akhirnya Anda akan tiba di Antarmuka Peran utama: antarmuka dengan metode tunggal. Ini sering terjadi pada saya. Ini sebuah contoh:
public interface IMessageQuery
{
string Read(int id);
}
Jika saya mengambil ketergantungan pada IMessageQuery
, bagian dari kontrak implisit adalah bahwa panggilan Read(id)
akan mencari dan mengembalikan pesan dengan ID yang diberikan.
Bandingkan ini dengan mengambil ketergantungan pada tanda tangan fungsional yang setara int -> string
,. Tanpa isyarat tambahan, fungsi ini bisa menjadi sederhana ToString()
. Jika Anda menerapkan IMessageQuery.Read(int id)
dengan ToString()
saya dapat menuduh Anda sengaja subversif!
Jadi, apa yang bisa dilakukan programmer fungsional untuk menjaga semantik antarmuka yang bernama baik? Apakah konvensional untuk, misalnya, membuat tipe rekaman dengan satu anggota?
type MessageQuery = {
Read: int -> string
}
Without any additional clues
... mungkin itu sebabnya dokumentasi adalah bagian dari kontrak ?