jump to navigation

Framework Design Guidelines Bagian 04 – Prinsip #1: Scenario-Driven Design 9 Mei 2008

Posted by firstyuyu in Prinsip Dasar.
trackback

Pada umumnya, sebuah framework terdiri dari kumpulan API yang sangat banyak. Hal ini disebabkan karena sebuah framework harus bisa mengakomodasi berbagai macam skenario penggunaan, dari yang paling sederhana hingga yang paling kompleks. Namun faktanya, sebagian besar developer hanya menggunakan sebagian kecil saja dari skenario yang ditawarkan sehingga sebenarnya hanya sebagian kecil saja dari framework yang sering digunakan. Untuk memaksimalkan produktivitas developer yang menggunakan framework kita, maka sangat penting bagi kita sebagai desainer framework untuk menginvestasikan sebagian besar waktu kita untuk merancang API bagi sebagian kecil skenario yang sering digunakan ini.

Kesalahan yang paling umum terjadi adalah seorang desainer framework biasanya menggunakan metode object oriented untuk merancang API. Masalahnya adalah metode-metode object oriented dibuat dan dioptimalkan untuk kemudahan maintenance dan implementasi internal dari sebuah framework. Ia tidak cocok digunakan untuk medesain public API sebuah framework yang menuntut usability yang tinggi.

Berikut ini panduan untuk prisip Scenario-Driven Design:

Lakukan:
Pastikan bahwa semua desain yang kita lakukan selalu merujuk ke spesifikasi API yang telah ditentukan.

Lakukan:
Tentukan sepuluh skenario yang paling sering digunakan untuk masing-masing fitur yang ada di framework kita.

Lakukan:
Pastikan bahwa skenario yang kita buat merupakan sebuah level abstraksi yang sesuai. Sebagai contoh, membaca sebuah file merupakan contoh skenario yang bagus. Sementara membuka file, membaca sebuah baris dari file teks, atau menutup file bukan merupakan skenario yang bagus. Mereka terlalu spesifik untuk dijadikan sebuah skenario.

Lakukan:
Desainlah API dengan cara menulis contoh penggunaan kodenya dahulu, baru kemudian membuat object model untuk mengakomodasi contoh penggunaan kode tersebut. Hal ini penting karena ketika menulis contoh penggunaan kode, maka pikiran kita akan diset untuk seolah-olah menjadi developer yang akan menggunakan framework tersebut sehingga kita akan merasakan apakah API yang kita buat akan mudah digunakan atau tidak dalam perspektif developer.

Sebagai contoh, misalnya kita ingin mendesain API untuk skenario yang ada pada sebuah stopwatch. Maka kita pertama kali menulis contoh kode yang akan menggunakan API tersebut seperti tampak di bawah:

// Skenario #1: Menghitung

// waktu yg dibutuhkan

Stopwatch s = Stopwatch.StartNew();

DoSomething();

Console.WriteLine(s.Elapsed);

 

// Skenario #2: Menggunakan

// kembali stopwatch yang

// telah ada

s.Reset();

s.Start();

DoSomething();

Console.WriteLine(s.ElapsedMiliseconds);

 

 

 

Setelah kita membuat contoh kode tersebut, barulah kita membuat object model yang bisa mengakomodasi contoh kode yang telah kita tulis. Dari contoh di atas, maka kita bisa membuat object model seperti berikut:

public class Stopwatch

{

    public static Stopwatch StartNew() { }

 

    public void Start();

    public void Reset();

 

    public TimeSpan Elapsed { get; }

    public long ElapsedMiliseconds { get; }

}
 

 

Lakukan:
Pada platform multi bahasa seperti .NET, maka tulislah contoh kode tersebut dalam minimal dua bahasa yang berbeda yang didukung oleh platform tersebut (misalnya: VB.NET dan C#). Hal ini penting karena bisa saja penulisan yang cukup intuitif di C# akan menjadi membingungkan ketika harus diterjemahkan ke dalam bahasa lain yang berbeda, misalnya VB.NET.

Jangan:
Menggunakan metodologi object oriented untuk medesain public API dari sebuah framework. Seperti telah dijelaskan di atas bahwa metodologi object oriented hanya cocok digunakan untuk desain internal dari sebuah framework. Ia tidak cocok digunakan untuk mendesain public API.

Lakukan:
Adakan usability test pada API yang ada di skenario utama. Hal ini bisa dilakukan dengan mengundang beberapa developer untuk mencoba public API buatan kita. Melalui usability test, kita bisa mengetahui sejauh mana kemudahan penggunaan public API kita. Usability test tidak harus menunggu implementasi selasai karena di sini kita hanya menguji skenario. Kita hanya ingin melihat apakah developer bisa menggunakan public API kita sesuai dengan skenario yang kita harapkan. Poinnya adalah, lakukan usability test di fase awal dari desain framework karena ketidak sesuaian yang kita dapatkan di awal akan lebih mudah diperbaiki daripada jika hal itu diketahui setelah framework jadi.

Komentar»

1. Wirawan Winarto - 12 Mei 2008

Wow! Those are great Scenario Driven Design info!