Framework Design Guidelines Bagian 05 – Prinsip #2: Low Barrier To Entry 9 Mei 2008
Posted by firstyuyu in Prinsip Dasar.trackback
Tren yang terjadi saat ini adalah sering kali seorang developer diharuskan mempelajari sebuah framework baru dengan cepat. Untuk mencapai hal ini, akan lebih mudah bagi mereka jika mereka bisa mulai menggunakan framework baru tersebut dengan cara bereksperiment (mencoba-coba) sesuai kebutuhan dan baru benar-benar mempelajari arsitekurnya secara keseluruhan jika memang itu benar-benar dibutuhkan. Misalnya ketika mereka harus berpindah dari skenario yang sederhana menuju ke skenario penggunaan yang lebih rumit.
Sangat mudah mendesain framework bagi developer yang mirip dengan kita, namun sangat sulit mendesain framework untuk developer yang berbeda sama sekali tipenya dengan kita. Terlalu banyak framework di pasaran yang didesain oleh domain expert dan hanya bisa digunakan dengan benar oleh domain expert juga. Masalahnya adalah bahwa kebanyakan developer bukanlah domain expert, tidak akan pernah menjadi dan memang tidak perlu menjadi ahli di semua teknnologi yang ada yang digunakan di aplikasi dewasa ini.
Sebuah framework harus menawarkan low barrier to entry kepada developer yang bukan ahli dengan cara mendesain public API-nya dengan benar sehingga memungkinkan seorang developer melakukan eksperimen terhadap framework tersebut sesuai kebutuhan tanpa harus mempelajari dahulu arsitektur keseluruhan dari framework tersebut. Berikut ini adalah panduan untuk prisip Low Barrier To Entry:
Lakukan:
Pastikan bahwa setiap namespace yang ditujukan untuk skenario utama hanya berisi entity yang terlibat dalam skenario utama.
Lakukan:
Jika memungkinkan, selalu sediakan overload yang lebih sederhana untuk setiap method maupun constructor.
Jangan:
Menempatkan member yang ditujukan untuk skenario yang lebih rumit ke dalam entity/class yang ditujukan untuk skenario utama.
Jangan:
Membuat developer harus menginstansiasi lebih dari satu tipe (class) pada skenario utama.
Jangan:
Membuat developer harus melakukan inisialisasi yang sangat banyak sebelum bisa menggunakan sebuah tipe/class pada skenario utama.
Lakukan:
Jika memungkinkan, selalu berikan nilai default yang tepat untuk setiap property dan parameter (menggunakan overloading yang lebih sederhana).
Lakukan:
Beritahukan kepada developer tentang kesalahan penggunaan API melalui exception. Penggunaan exception di sini menjadi penting karena dengan menggunakan exception, developer tidak bisa mengabaikan jika terjadi kesalahan. Hal ini berbeda dengan mengkomunikasikan kesalahan menggunakan return value yang bisa diabaikan oleh developer. Yang kedua, exception bisa lebih jelas dalam menginformasikan kesalahan yang terjadi dibandingkan dengan return value yang hanya berisi kode-kode kesalahan tanpa deskripsi yang jelas.
Poin-poin di atas bisa kita ilustrasikan dengan contoh berikut. Yang pertama, kita akan melihat contoh kode yang digunakan untuk mengambil data dari Ms SQL Server.
SqlConnection con = new SqlConnection();
con.ConnectionString = “…”;
SqlCommand cmd = new SqlCommand();
cmd.CommandText = “SELECT * FROM Customer”;
cmd.Connection = con;
SqlDataAdapter da = new SqlDataAdapter();
da.SelectCommand = cmd;
DataSet ds = new DataSet();
da.Fill(ds);
// Tampilkan isi Dataset
// …
Dari kode di atas kita bisa lihat bahwa untuk melakukan skenario paling sederhana yang berkaitan dengan database (mengambil data), kita harus menginstansiasi beberapa kelas, menentukan asosiasi di antara mereka, serta melakukan beberapa inisialisasi property. Tentu hal ini akan membingungkan terutama bagi developer baru yang mungkin dia hanya ingin membaca data dari database saja.
Sekarang kita lihat contoh API untuk menulis ke dalam eventlog. Kodenya sebagai berikut:
EventLog log = new EventLog();
log.Source = “Mailing Service”;
log.WriteEntry(“Mail Arrived”);
Di sini bisa kita lihat, untuk melakukan skenario paling sederhana, developer cukup menginstansiasi sebuah kelas saja. Lalu melakukan sebuah inisialisasi dan obyek EventLog siap digunakan untuk menulis ke dalam eventlog Windows. Pada kelas EventLog, sedikitnya inisialisasi yang kita lakukan disebabkan karena kelas EventLog telah memberikan nilai default yang tepat ketika kita menginstansiasinya. Jika kita memang dibutuhkan, kita bisa memodifikasi nilai property lainnya. Namun biasanya hal ini jarang dilakukan kecuali dalam skenario penggunaan yang lebih kompleks. Jadi pemberian nilai default di sini sangat membantu dalam menyederhanankan penggunaan kelas EventLog.
Namun satu hal yang perlu diingat bahwa pemberian nilai default harus tepat. Jangan sampai pemberian nilai default justru akan menyebabkan terjadinya lubang keamanan atau penurunan performa aplikasi. Jika demikian, lebih baik tidak perlu memberikan nilai default.

“Beritahukan kepada developer tentang kesalahan penggunaan API melalui exception.”
Coba tulis juga donk cara merancang exception.
Karena kadangkala ada problem yang fits ke dalam lebih dari satu macam error. Adakah guidelines untuk perancangan exception?
Masukan yang bagus. Iya, rencananya nanti akan nulis tentang itu juga. Smg nanti bisa kita jadikan bahan diskusi
Udah Wan, aku lagi nulis seri tentang Exception Design. Cari aja menggunakan kotak search di kanan atas dengan keyword “Exception Design”