Feeds:
Posts
Comments

Kali ini, seperti janji di akhir postingan Strategy Pattern Bagian 2, kita akan mengintegrasikan duck behaviors ke dalam kelas Duck. Kuncinya, Duck sekarang akan mendelegasikan flying dan quacking behaviors, dan bukan mendefinisikan flying dan quacking method di class Duck atau subclasses-nya.

Bagaimana caranya? 

Ok, kita akan melihat dulu kelas Duck yang telah dimodifikasi. Kelasnya akan seperti ini.
new-duck1

Kenapa kelas Duck menjadi seperti itu, ini langkah-langkahnya.

Pertama, kita menambahkan dua instance variables ke dalam kelas Duck. Sebut saja flyBehavior dan quackBehavior. Dua instance variables ini dideklarasikan dengan bertipe interface dan bukan bertipe implementasi konkrit. Tiap objek Duck akan men-set variables ini secara polimorfis dengan reference dari behavior type tertentu yang diinginkan saat runtime, misalnya FlyWith Wings, Quack, dsb. 

Kita juga menghapus method fly() dan quack() dari kelas Duck serta subclasses-nya karena kita telah memindahkan behavior ini ke kelas-kelas FlyBehavior dan QuackBehavior.
fly() dan quack() pada kelas Duck diganti dengan dua method yang mirip yang dinamakan dengan performFly() dan performQuack(). Cara kerja dari kedua method ini akan kita lihat sebentar lagi.

Kedua, kita implementasikan performQuack():

public class Duck {
    QuackBehavior quackBehavior;
    // kode lainnya

    public void performQuack() {
       quackBehavior.quack();
    }
}

Masing-masing Duck mempunyai reference ke sesuatu yang mengimplementasikan interface QuackBehavior.

Untuk melakukan quack, sebuah objek Duck tinggal mengijinkan objek yang di-reference oleh quackBehavior untuk ber-quack. Jadi, pada kode ini kita tidak peduli objek macam apa ini, yang kita pedulikan yaitu objek ini tahu bagaimana untuk ber-quack().

Ketiga, kita men-set instance variables flyBehavior dan quackBehavior. Tapi bagaimana caranya? Ok, sekarang kita lihat kelas MallardDuck:

public class MallardDuck extends Duck {
    public MallardDuck() {
        quackBehavior = new Quack();
        flyBehavior = new FlyWithWings();
    }
    public void display() {
        System.out.println("Saya adalah Mallard duck");
    }
}

Seekor MallardDuck menggunakan kelas Quack untuk menangani suara kwek-nya. Ketika performQuack dipanggil, tanggung-jawab untuk ber-kwek didelegasikan kepada objek Quack. Kemudian kita dapat suara kwek-kwek-kwek. Untuk flyBehavior-nya, MallardDuck menggunakan FlyWithWings.

Kenapa bisa seperti ini? Ketika MallardDuck di-instance-kan, constructor-nya meng-inisialisasi instance variable quackBehavior dengan instance baru yang bertipe Quack() (kelas yang merupakan implementasi konkrit dari QuackBehavior). Begitu juga dengan flying behavior. Constructor dari MallardDuck meng-inisialisasi instance variable flyBehavior dengan instance dari FlyWithWings yang merupakan kelas implementasi konkrit dari FlyBehavior.

CODING TIME!

Setelah kita berkata-kata panjang lebar, saatnya untuk sedikit melakukan coding dan compile untuk mengetes solusi di atas. 

Pertama, kita tuliskan kode kelas Duck (Duck.java) dan kelas MallardDuck (MallardDuck.java).

public abstract class Duck {

    FlyBehavior flyBehavior;
    QuackBehavior quackBehavior;

public Duck() {
}
public abstract void display();

public void performFly() {
    flyBehavior.fly();   // mendelegasikan ke behavior class
}

public void performQuack() {
    quackBehavior.quack();   // mendelegasikan ke behavior class
}

public void swim() {
    System.out.println("Saya Berenang....!");
    }
}
public class MallardDuck extends Duck {
    public MallardDuck() {
        quackBehavior = new Quack();
        flyBehavior = new FlyWithWings();
    }
    public void display() {
        System.out.println("Saya adalah Mallard duck");
    }
}

Kemudian kita compile.

Selanjutnya, kita tuliskan kode interface FlyBehavior (FlyBehavior.java) dan dua kelas implementasi behavior FlyWithWings (FlyWithWings.java) dan FlyNoWay (FlyNoWay.java).

public interface FlyBehavior {
	public void fly(); // method fly perlu di-override oleh
			   // class yang mengimplementasikan
			   // interface ini
}
public class FlyWithWings implements FlyBehavior {
	public void fly() {
		System.out.println("Saya terbang....!");
	}
}
public class FlyNoWay implements FlyBehavior {
	public void fly() {
		System.out.println("Saya tidak dapat terbang :( ");
	}
}

Kemudian kita compile.
Selanjutnya, giliran interface QuackBehavior (QuackBehavior.java) dan tiga kelas implementasinya yaitu Quack.java, MuteQuack.java, dan Squeak.java.

public class Quack implements QuackBehavior {
	public void quack() {
		System.out.println("Quack.....");
	}
}
public class Squeak implements QuackBehavior {
	public void quack() {
		System.out.println("Squeak....");
	}
}
public class MuteQuack implements QuackBehavior {
	public void quack() {
		System.out.println("<< Tidak bersuara >>");
	}
}

Kemudian kita compile juga.
Kelas-kelas kita sudah dituliskan. Sekarang saatnya mengetes kelas-kelas tersebut dengan membuat kelas tester. Jadi tester yang digunakan adalah kelas seperti ini (MiniDuckSimulator.java).

public class MiniDuckSimulator {
	public static void main(String[] args) {
		Duck mallard = new MallardDuck();
		mallard.performQuack();
		mallard.performFly();
	}
}

Kita compile, dijalankan dan outputnya adalah…….
output-mallardduck
Yep, sesuai dengan yang kita harapkan.
Ok, ini bukanlah akhir cerita. Kita belum menyinggung apanya yang dinamakan Strategy Pattern. Oleh karena itu kita perlu wrap-up cerita panjang ini dan itu akan dilakukan di postingan selanjutnya di Strategy Pattern Bagian 4. Don’t miss it….

Postingan ini merupakan lanjutan postingan sebelumnya pada Strategy Pattern bagian 1. Permasalahan yang dihadapi Joe ternyata tidak dapat diatasi dengan inheritance maupun interface, tetapi dengan, yeah you guess, … design pattern. Untuk menjelaskan bagaimana salah satu design pattern memecahkan masalah ini, kita coba aplikasikan dulu prinsip-prinsip OO design yang baik. 

Sekarang dimulai dengan isu, bahwa CHANGE (huruf besar untuk penekanan) merupakan faktor yang sering terjadi dalam pengembangan software. Tidak peduli bagaimana aplikasi tersebut didesain dengan baik, dalam rentang waktu mendatang, aplikasi harus berkembang dan berubah atau aplikasi tersebut mati.

Jadi, back to story, inheritance yang digunakan Joe ternyata tidak berjalan dengan baik, karena behavior dari duck terus berubah. Behavior tersebut juga tidak cocok dimiliki semua subclass. Setali tiga uang dengan interface. Penggunaan interface Flyable dan Quackable mulanya menjanjikan karena hanya duck yang benar-benar bisa terbang yang mengimplementasikan Flyable. Namun interface tidak memiliki kode implementasi, sehingga tidak bisa reuse. Jika ingin melakukan modifikasi pada behavior, maka kita harus menelusuri semua subclass dimana behavior tersebut didefinisikan untuk kemudian diubah. Tentu bisa memberikan peluang terjadinya bug baru!

Untungnya, terdapat suatu prinsip design untuk situasi ini. 

Prinsip Design:

Identifikasi aspek-aspek pada aplikasi yang berubah dan pisahkan dari yang tetap.

Dengan kata lain, jika terdapat kode yang berubah, misal akibat dari requirement baru, maka behavior ini perlu diambil dan dipisahkan dari semua aspek yang tidak berubah. Istilah lainnya meng-encapsulate yang berubah sehingga kita dapat mengubah atau meng-extend bagian-bagian yang berubah tanpa mempengaruhi yang lain. Konsep ini sebenarnya merupakan dasar dari hampir semua design pattern. Wow!

Sekarang mari kita mengambil behavior dari class Duck. Tapi behavior yang mana? Selain fly() dan quack(), tidak ada bagian dari class Duck yang cenderung berubah. Sehingga class Duck bisa dibiarkan seperti semula dengan sedikit modifikasi. Untuk memisahkan bagian yang berubah dari yang tetap, kita buat dua set kelas, satu untuk fly dan satu untuk quack. Masing-masing set kelas berisi semua implementasi dari behavior fly dan quack. Misalnya satu kelas yang mengimplementasikan quacking, satu kelas lain mengimplementasikan squeaking, dan kelas yang lain yang mengimplementasikan silence. Kelas-kelas ini membentuk satu set kelas yang mengimplementasikan behavior quack. You get the idea

Ambil fly() dan quack() dari class Duck

Ambil fly() dan quack() dari class Duck

 

MENDESAIN DUCK BEHAVIORS

Sekarang, bagaimana cara kita mengimplementasikan set kelas-kelas ini yang mengimplementasikan behavior fly dan quack?

Tentu desainnya harus fleksibel, karena masalah yang dialami Joe ini bermula dari tidak fleksibelnya behavior duck pada desain awal. Dan kita tahu kita ingin meng-assign behavior kepada instance-instance dari Duck. Misalnya, kita ingin membuat instance MallardDuck yang baru dan menginisialisasinya dengan tipe khusus dari flying behavior. Atau lebih jauh lagi, kita dapat mengganti behavior dari suatu duck secara dinamik. Dengan kata lain, kita memasukkan method yang bertugas sebagai setter behavior sehingga dapat mengubah flying behavior dari MallardDuck saat runtime!

Untuk mencapai hal ini, kita perlu lihat prinsip design yang kedua.

Prinsip Design:

Memprogram dengan interface, bukan dengan implementasi.

Apa maksudnya? 
Kita akan menggunakan interface untuk merepresentasikan masing-masing behavior, misalnya interface FlyBehavior dan QuackBehavior. Dan tiap-tiap implementasi dari behavior akan mengimplementasikan salah satu dari interface ini.

Jadi, kali ini bukan class Duck atau subclassnya yang mengimplementasikan interface FlyBehavior dan QuackBehavior. Melainkan, dua set kelas tadi yang telah dibahas sebelumnya pada bagian encapsulate. Dan dua set kelas ini berupa, sebut saja behavior class, karena alasan dibuat adalah untuk merepresentasikan behavior dengan mengimplementasikan behavior interface.

Cara ini berbeda dengan cara yang digunakan sebelumnya. Cara sebelumnya, behavior-nya berasal dari implementasi konkrit di superclass Duck, atau dari implementasi spesifik di subclass. Kedua kasus tersebut mengandalkan pada implementasi. Kita terkunci oleh implementasi spesifik dan tidak ada ruang, selain me-rewrite code, untuk mengganti behavior.

Dengan desain yang baru, subclass dari Duck akan menggunakan behavior yang direpresentasikan oleh interface (FlyBehavior dan QuackBehavior). Dengan demikian, implementasi konkrit dari behavior tidak akan stuck pada subclass Duck.
      

Interface dari flying behavior

Interface dari flying behavior

 

Poin dari cara ini adalah ingin memanfaatkan polimorfisme. Artinya tipe variabel yang dideklarasikan harus supertype, biasanya berupa abstract class atau interface, sehingga objek yang di-assign ke variabel tersebut dapat berupa implementasi konkrit dari supertype. Dengan begitu, kelas yang mendeklarasikan variabel ini tidak perlu tahu tipe aktual dari object!

Inilah contoh yang menjelaskan konsep polimorfisme. Bayangkan suatu abstract class Animal dengan dua implementasi konkritnya, Dog dan Cat.

 

Abstract class Animal dengan dua implementasi Dog dan Cat

Abstract class Animal dengan dua implementasi Dog dan Cat

  

Memprogram dengan implementasi akan seperti:
Dog d = new Dog();
d.bark()
Mendeklarasikan variabel “d” sebagai tipe Dog (implementasi konkrit dari Animal) memaksa kita coding dengan implementasi konkrit.
Tetapi memprogram dengan interface/supertype akan seperti:
Animal animal = new Dog();
animal.makeSound();
Kita tahu objek ini Dog, tetapi sekarang kita dapat menggunakan reference Animal secara polimorfis.
Dan, daripada hard-coding peng-instance-an (seperti, new Dog()), kita dapat meng-assign implementasi konkrit objek saat runtime:
Animal animal = getAnimal();
animal.makeSound();
Kita tidak tahu apa subtype aktual animal. Tetapi, kita tahu bahwa subtype animal ini tahu bagaimana merespon makeSound(). Polimorfisme bekerja!
  

Mengimplementasikan Duck Behaviors
Jadi, kembali lagi ke permasalahan duck behaviors. Kita dapat mempunyai dua interfaces, yaitu FlyBehavior dan QuackBehavior. Masing-masing interfaces tersebut memiliki kelas-kelas yang mengimplementasikan interface ini. Ini dia rancangannya:
Implementasi behaviors Duck

Implementasi behaviors Duck

Dengan desain ini, objek lainnya dapat me-reuse behavior fly dan quack karena behavior ini tidak tersembunyi di kelas-kelas Duck. Selain itu, kita dapat menambahkan behavior baru tanpa harus memodifikasi behavior class yang sudah ada atau menyentuh kelas-kelas Duck yang menggunakan behavior ini.
Jadi solusi permasalahan yang dihadapi Joe seperti apa? Kok muter-muter begini.
Ok, sabar. Tadi itu merupakan penjelasan ide yang akan digunakan untuk memecahkan masalah yang dihadapi Joe. Just to make sure there is no such a high leap.
Untuk selanjutnya, kita tinggal mengintegrasikan duck behavior ini ke kelas Duck. Tapi itu untuk postingan selanjutnya di Strategy Pattern bagian 3. Di sana, kita akan mengimplementasikannya sekaligus mengetesnya. Keep stay tuned…. 

 

 

 

Pattern pertama yang dipost-kan dalam blog ini bernama Strategy Pattern. Pattern ini juga yang pertama kali didemonstrasikan pada buku Head First Design Pattern. Pada postingan kali ini, saya ingin menceritakan kembali ilustrasi yang diberikan pada buku tersebut. Senang rasanya membaca buku yang sangat menarik dan unik ini. Selain mendapat pencerahan tentang design pattern, buku ini juga dipenuhi gambar-gambar ilustrasi. Bahkan tulisan-tulisan cuma mendapat porsi yang lebih sedikit dibanding gambar ilustrasinya. But it works anyway, at least for me. Saya menjadi tahu apa itu design pattern. 

120px-duckpondatari

Simulasi bebek-bebek mungil

Ceritanya, ada seorang programmer OO bernama Joe yang bekerja di suatu software company. Perusahaan tersebut membuat game simulasi bebek-bebek di kolam, yang diberi nama SimUDuck. SimUDuck dapat menunjukkan berbagai spesies bebek yang berenang dan membuat suara kwek-kwek. Game ini pada mulanya dibuat dengan teknik Object-Oriented dan menggunakan superclass Duck sehingga dapat di-inherit oleh semua tipe bebek.

duck-first-design

Desain Awal SimUDuck

Karena adanya game saingan dari kompetitor, perusahaan ini ingin mengembangkan SimUDuck dengan tambahan fitur yang lebih menarik. Mereka ingin membuat bebek-bebek tersebut bisa terbang. Dengan begitu, mereka dapat mengalahkan kompetitor mereka. Dan Joe, sebagai programmer perusahaan, diberikan tugas mem-program requirement tersebut. Joe merasa tidak ada yang susah, karena dia berpikir tinggal menambahkan method fly() ke class Duck, dan Done! 

Joe menambahkan method fly() pada superclass Duck

Joe menambahkan method fly() pada superclass Duck

Saat demonstrasi program, tiba-tiba sesuatu yang buruk terjadi. Bebek-bebek karet (rubber duckies) beterbangan kemana-mana di layar! Apakah ini lelucon? Rubber duckies harusnya tidak dapat terbang. Joe lupa bahwa tidak semua bebek bisa terbang. Ketika Joe menambahkan behaviour baru pada superclass Duck, ia juga menambahkan behaviour yang tidak cocok dengan beberapa subclass dari Duck. Jadi, update yang localized pada kode malah menyebabkan efek samping yang tidak lokal (misal. bebek-bebek karet yang bisa terbang).
Rubber duckie dapat terbang!

Rubber duckie dapat terbang!

f
INHERITANCE (Bukan solusi yang bagus untuk kasus ini)
Joe berpikir dengan inheritance bisa memecahkan kasus penambahan requirement terbang ini. Ia dapat meng-override method fly() pada rubber duck. Ia tinggal membiarkan kosong method fly() pada rubber duck. Hal ini sama seperti cara ia meng-override method quack(). Tetapi apa yang akan terjadi ketika akan menambahkan bebek kayu (wooden duck) pada program? Mereka tidak seharusnya bisa terbang dan juga bersuara kwek (quack). Joe sadar inheritance mungkin bukan jawabannya, karena produk ini terus-menerus diupdate. Joe tahu spec akan terus berubah, artinya ia harus terus memeriksa dan kemungkinan meng-override fly() dan quack() untuk tiap subclass baru dari Duck. Joe butuh cara yang lebih efektif yang memungkinkan ia mempunyai beberapa bebek (tidak semua) yang dapat terbang dan berkwek.
inheritance-not-solution
f
INTERFACE (Still, bukan solusinya)
Joe kemudian berpikir ke interface. Ia dapat mengeluarkan fly() dari superclass Duck dan membuat interface Flyable() dengan method fly(). Dengan begitu, hanya bebek yang bisa terbang yang akan mengimplementasikan interface ini dengan mempunyai method fly(). Begitu juga dengan quack(), ia dapat membuat interface Quackable, karena tidak semua bebek dapat bersuara kwek. Tapi coba pikir tentang duplikasi kode? Dengan interface, Joe harus menuliskan method fly() di semua subclass yang mengimplementasikan interface Flyable(). Bagaimana kalau terjadi perubahan pada method fly()? What a Pain!
Masih harus mengimplementasikan fly() satu-per-satu

Masih harus mengimplementasikan fly() satu-per-satu

Kalau saja ada cara untuk mengembangkan software sehingga jika kita perlu mengubahnya, kita dapat melakukannya dengan efek yang terkecil pada kode yang sudah ada? Kalau saja ada, kita hanya perlu waktu sebentar untuk merevisi kode dan membuat software yang lebih keren?
Ok, solusinya ada di postingan berikutnya pada Strategy Pattern (Bagian 2). Stay tuned ……..
 

Istilah design patterns dimulai di bidang perancangan bangunan oleh Christopher Alexander. Dalam bukunya A Pattern Language [Alex77], ia menerangkan pola-pola yang terdapat di dalam berbagai rancangan arsitektur bangunan. Arti design pattern diterangkannya dalam kalimat berikut:

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice [Alex77].

Design patterns adalah unsur-unsur rancangan yang seringkali muncul pada berbagai sistem yang berbeda. Setiap kemunculan ini menguji pattern tersebut di berbagai situasi. Ada juga yang mengartikan istilah design pattern sebagai sebuah solusi untuk mengulang masalah design. Solusi ini telah dikembangkan, dicompile, dan disaring oleh programmer yang sebelumnya telah menghadapi masalah ini. Design pattern pada dasarnya merupakan petunjuk atau langkah-langkah dalam menyelesaikan solusi, mirip seperti halnya dengan algoritma. Sebagai contoh : jika kita ingin melakukan sebuah operasi pencarian pada sebuah daftar bilangan, kita tidak perlu menyelesaikan dengan solusi kita sendiri, terdapat beberapa algoritma yang menyediakan fungsi searching ini seperti binary tree searching.

Perbedaan antara design pattern dan algoritma adalah algoritma fokus pada implementasi solusi.  Sebuah algoritma biasanya me-list dari atas ke bawah menuju ke tahap akhir dengan statement yang terurut  untuk menghasilkan sebuah solusi. Sedangkan design pattern menginformasikan kepada developer apa yang harus dilakukan, bukan bagaimana cara melakukannya.

Teman dari jurusan Teknik Penerbangan pernah bertanya: Apa yang membedakan Java (Object-Oriented Language) dengan C atau Pascal? Selain sintaks tentunya…

Meskipun dari Teknik Penerbangan, teman saya pernah mendapatkan kuliah pemrograman dengan bahasa Pascal. Mungkin teman saya melontarkan pertanyaan itu, setelah mendengar hype tentang Object-Oriented Programming yang rame belakangan ini. Oops, mungkin bukan sekedar hype.

Saya belum pernah benar-benar mencicipi Java (bukan kopi). Ok, pernah, tapi menggunakan Java hanya untuk get the job done :) . Jadi, saya tidak tahu persis jawabannya. Saya asal jawab saja: re-use.

Diberikan jawaban tersebut, teman saya masih belum puas. Dia kemudian bilang:
Buat fungsi-fungsi di, katakanlah, suatu library. Kemudian fungsi tersebut dipakai pada program-program kita yang membutuhkannya.
See, it’s also re-use. I don’t have to write them from scratch.

#include <stdio.h>
main()
{
printf("Hello World!\n");
}

Jika program lain ingin mencetak string di standard output (layar monitor), bisa menggunakan printf juga.

Ada konsep inheritance di OOP. Tapi mungkin itu masih bisa diimplementasikan di bahasa yang tidak memiliki fitur OOP, C misalnya, meskipun dengan susah payah. Nah, mungkin bahasa dengan fitur OOP menyediakan cara yang lebih mudah untuk mengimplementasikan desain yang berorientasi objek (Object-oriented Design). Bahasa dengan fitur OOP tidak hanya memiliki scope fungsi dan module (e.g file), tetapi juga ada tambahan scope class dalam module.

Ada yang bisa menambahkan atau mengurangi atau malah mengubah jawaban di atas sehingga teman saya terpuaskan?

Picture’s Credit: http://heim.ifi.uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_OO_start.html

Akhirnya masa liburan telah usai, dan tibalah masa kuliah. Kuliah semester ini diawali dengan kuliah Object-Oriented Programming (OOP). Instruktur dari kuliah ini adalah Pak Edi Winarko.

Seperti kuliah-kuliah pertama lainnya, pada kuliah ini membahas introduction to object-oriented programming. Sebelum dibahas, perlu diingatkan, bahasan pada blog ini merupakan interpretasi pribadi dari orang yang masih belajar.
Jadi, bila ada yang tidak benar merupakan kesalahan penulis. That’s it. Now continue…

Objek

Ketika mendengar Object-oriented programming, yang terlintas di benak pertama kali mungkin pertanyaan,

“Apa itu objek? You must define it first”, They say.

Hmmm well, menurut lecture notes di:
http://burks.bton.ac.uk/burks/pcinfo/progdocs/oocourse/ooc/obj1/lesson1.htm

Bukalah mata anda dan anda sudah melihat objek. Mungkin di sebelah ada mahasiswa, dosen, kucing, atom, es krim, es buah, politikus, Bandung Bondowoso. Dunia dibangun dari objek-objek.
Tentu ini bukanlah definisi yang rigor. Tapi saya tahu, anda tahu, dan kita sama-sama tahu apa maksudnya. After all we’re not mathematicians. We just want to build interesting systems with those objects.

Objek dapat dideskripsikan lewat atribut dan operasinya. Atribut merupakan karakteristik objek yang bisa berubah. Katakanlah, tinggi, berat, warna rambut, mencerminkan atribut dari manusia. Operasi merupakan hal-hal yang objek bisa lakukan atau yang bisa dilakukan terhadap objek tersebut. Manusia bisa berolahraga, berdiet, menyemir rambut, atau dicintai. Pada notasi OOP, objek manusia digambarkan seperti ini.

Objek Manusia

Objek Manusia

 

 

Untuk contoh pemodelan objek-objek yang lain, bisa dilihat di lecture notes pada alamat di atas. Banyak contoh yang menarik di sana. Ada Wolf dan Grandma (Ingat dongeng Serigala dan Nenek, Serigala ingin memakan nenek kalau tidak salah), red riding hood (saya tidak tahu dongeng tentang apa ini), dan juggling ball (contoh yang aneh).

Sedikit tentang lecture notes, saya sudah membaca lecture notes lesson 1. Bahasannya cukup menarik, jelas, dan mudah dipahami. Bagi yang sebelumnya merasa OOP adalah nightmare (seperti saya), maka disarankan membaca lecture notes ini.

Hanya satu kekurangannya, No Code. Karena itu, cari juga sumber lainnya untuk mengimplementasikan konsep-konsep ini. Kalau saya, baca lecture notes dan baca OOP pada PYTHON. Yes, I love those Monthy Python! (Mungkin baca JAVA juga, karena diperlukan pada kuliah ini)

Cukup tentang objek, tapi masih ada konsep-konsep OOP berikutnya yang menarik seperti inheritance, composition, class diagram, sequence diagram, etc. We are still in the edge of the OOP Ocean. Konsep ini mungkin dibahas pada postingan berikutnya.

Hari Selasa kemarin merupakan hari pertama kuliah Pemrograman Berorientasi Objek. Sebetulnya jadwal awal kuliah dimulai pada minggu lalu. Tetapi karena Pak Edi (dosen kuliah ini) sedang ada keperluan, kuliah baru bisa start pada minggu ini.

Di akhir kuliah, Pak Edi memberikan tugas untuk tiap kelompok membuat blog. Karena itu, blog ini menjadi hidup mulai sekarang.

Semua anggota kelompok yang membuat blog ini masih dalam level beginner untuk urusan blog-mengeblog. Jadi selain untuk tugas kuliah, blog ini dijadikan sarana belajar menulis (nge-blog). Apalagi saat ini sudah memasuki era WEB 2.0 (They say) yang ditandai dengan maraknya jejaring sosial lewat dunia maya. Blog ini maunya sebagai kontribusi sharing informasi di antara para penghuni internet. Syukur-syukur kalau bisa bermanfaat bagi yang tersesat ke blog ini dan kemudian membacanya.

Mengenai isi blog, blog akan diisi informasi tentang object-oriented programming. Dan mungkin ada yang bertanya (kalau ada) apakah blog ini akan di-update secara kontinyu (atau diskrit?) ? Well, jawaban dari pertanyaan tersebut yaitu kita lihat saja nanti…

Hello world!

Hello World! Our group members are:

  • Aji Febri Atmoko — 259507
  • Agus Qomaruddin — 259908
  • Anton Topadang — 263405

« Newer Posts