Sisi Baik dan Buruk Design Decision Pemrograman C#

Istilah design-decision sering dipakai untuk mengacu kepada putusan perancangan perancang dari produk-produk seperti bahasa pemrograman, kakas pemrograman, sistem operasi, DBMS, dan lain-lain. Sebagai sebuah produk, pembuat C# membuat design-decisions sendiri.

Pembahasan kali ini bertujuan mengungkapkan design-decision pada C# tentang nested block, dan repetisi dengan for(). Tujuan selanjutnya adalah mengajak pembaca memikirkan sisi baik dan sisi buruk design-decision pembuat C# dalam hal nested-block dan for.

Seperti kita tahu, penanda scope program atau biasa disebut dengan block selalu ada dalam setiap penulisan program. Biasanya diawali dengan tanda pembuka dan tanda penutup. Kali ini, kita akan membahas tentang block pada bahasa pemrograman C#.

Nested Block: Objects with Distinct Names

Mari kita mulai dengan contoh program Block01:

using System; // Program Block01 namespace Block01

class Module01

{

static void Main (string[] args)

{

int i = -1;

Console.WriteLine(“{0}”, i);

{

int j = -2;

Console.WriteLine(“{0}”, j);

}

}

}

}

Program ini tidak memiliki error apapun. Runnable-code yang dihasilkan (secara tidak langsung) dari source code di atas dapat di-run, dan hasilnya:

• -1
• -2

Nested Block: Objects with Same Names

Bagaimana kalau ada dua objek pada blok yang berbeda, tetapi dengan nama yang sama? Daripada berteori saja, mari kita coba. Berikut adalah source code-nya:

using System; // Program Block02

class Module01

{

static void Main (string[] args)

{

int i = -1;

Console.WriteLine(“{0}”, i);

{

int i = -2;

Console.WriteLine(“{0}”, i);

}

}

}

Dari hasil compile module tersebut terdapat error yang mengatakan bahwa objek i tidak dapat dideklarasikan ulang pada block selanjutnya, karena sudah dideklarasikan sebelumnya.

Objek pada Child-block Invisible ke Parent-block

Bagaimana bila deklarasi dilakukan di dalam bagian block seperti pada program di bawah ini:

using System; // Program Block03

class Module01

{

static void Main (string[] args)

{

int i = -1;

Console.WriteLine(“{0}”, i);

{

int j = -2;

Console.WriteLine(“{0}”, j);

}

Console.WriteLine(“{0}”, j);

}

}

Dalam program Block03 objek j didefi nisikan di nested block. Sedangkan pada bagian bawah, di luar block tersebut terlihat ada pemakaian objek j untuk menampilkan nilainya. Saat compile, akan muncul error yang mengatakan bahwa objek j tidak bisa diakses. Compiler melaporkan objek tersebut tidak ada dalam konteks, berbeda dengan program Block02 yang memunculkan error deklarasi ganda.

Dari contoh Module01, pada Program Block03 dapat disimpulkan bahwa block berfungsi untuk membatasi akses terhadap objek-objek yang ada di dalamnya.

Namespace dan Operasi for: (1)

Kita akan lihat keterkaitan namespace (dalam wujud block) dengan suatu operasi repetisi, yakni for(). Keterkaitan dikaji lewat program yang ke-4 ini, yang bernama Block04:

using System; // Program Block04

class Module01

{

static void Main (string[] args)

{

int i = -1;

Console.WriteLine (“{0}”, i);

for (int j = -2; j < 2; j++)

{

Console.WriteLine (“{0}”, j);

}

Console.WriteLine(“Exiting the block: {0}”, j);

}

}

Mengapa hal namespace perlu dikaitkan dengan operasi for()? Karena:

• Operasi for() yang banyak dijumpai di beberapa bahasa pemrograman. Saat ini dipengaruhi oleh keputusan perancangan pembuat C++ pada dekade 1980-an, yang m e m u n gkinkan inisalisasi objek (lihat contoh program Block04) di pemanggilan operasi for().
• Keterkaitan yang akan diungkap di tulisan ini belum pernah kami temukan di beberapa buku teks yang kami baca.

Pada contoh pertama dari program yang memakai operasi for(), kami pakai cara yang sedang tren. Sepengetahuan kami, banyak programmer yang tidak mengetahui efek buruk dari cara yang sedang tren ini. Paparan ini sekaligus memberi warning kepada programmer untuk tidak asal ikut tren.

Apa risiko dari pemakaian cara baru dari operasi for()? Risikonya adalah Anda tidak dapat memeriksa nilai counter saat ada kejadian yang tidak diinginkan. Pemeriksaan nilai counter perlu untuk pengkajian rinci penyebab kesalahan, seperti yang terlihat dari program ke-5 ini:

using System; // Program Block05

class Module01

{

static void Main(string[] args)

{

int[] ArrayObject1 = {-1, 0, 1};

for (int j = 0; j < 3; j++)

{

if (ArrayObject1[j] != 0)

continue;

else

break;

}

Console.WriteLine (“Exiting the block: {0}”, j);

}

}

Kompilasi modul utama pembentuk program Block05 akan gagal, karena ope rasi WriteLine mengakses objek j, sedangkan objek tidak visible pada namespace dimana operasi WriteLine dipanggil. Objek j dideklarasikan, bahkan sebenarnya didefi nisikan, di pemanggilan operasi for() sehingga namespacenya adalah child-block. Sesuai aturan yang disebutkan saat penjelasan program Block03, objek yang dideklarasikan/ didefi nisikan pada child-block akan invisible pada parent-block.

Namespace dan Operasi for: (2)

Programmer cenderung membuat program sesingkat mungkin. Karena itulah banyak programmer menyukai cara pemanggilan operasi for() yang sedang trendy, seperti pada program sebelumnya. Tapi banyak programmer juga tidak cukup meneliti efek baik dan buruk dari sesuatu yang sedang tren, karena berbagai sebab dan alasan.

Kami anjurkan deklarasi/definisi objek diluar pemanggilan operasi for(). Ini cara klasik, tapi terbukti mampu mengatasi masalah yang terkait dengan aturan pada namespace. Solusi dengan cara klasik ini, kami tulis pada program Block06:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace Block06

{

class Module01

{

static void Main(string[] args)

{

int[] ArrayObject1 = {-1, 0, 1};

int j;

for (j = 0; j < 3; j++)

{

if (ArrayObject1[j] != 0)

continue;

else

break;

}

Console.WriteLine (“Exiting the block: {0}”, j);

}

}

}

Pada program tersebut, objek j dideklarasikan diluar pemanggilan operasi for(). Sebagai efeknya, kita dapat memeriksa nilai counter saat ada yang tidak diinginkan dalam pemanggilan operasi for().

Penutup

Topik tentang namespace adalah topik yang penting. Tetapi pembahasan tentang topik ini seperti pada standar tentang C# atau buku pemrograman sangat buruk, lihat pustaka tentang C# yang menyertai tulisan ini. Buruknya pembahasan di standar dan buku pemrograman juga karena pengarangnya sering mengaitkan namespace dengan keyword. Penjelasan yang berdasarkan keyword tidak bersifat ilmiah.

Pada tulisan ini dijelaskan tentang namespace pada namespace mendasar yang hadir pada semua bahasa pemrograman: block. Dengan demikian, penjelasan ini tidak tergantung pada keyword. Selain itu, pada tulisan ini dijelaskan efek buruk pada cara pemanggilan operasi for() yang sedang trendy.

Pembahasan namespace pada tulisan ini didasarkan pada buku teks karangan penulis kedua, yang berjudul Modular Programming: A Revolutiona ry Approach. Buku ini sudah diuji pada universitas tempat penulis kedua mengajar.

Sisi Baik dan Buruk Design Decision Pemrograman C# telah kita kupas sedikit, yang pasti terdapat banyak kekurangan namun harapan saya bisa memberikan pencerahan terutama bagi saya sendiri.