Thursday, March 18, 2004
Cerita / bincang / membebel tentang OO (Object Oriented) - diambil dpd postings saya kat ittutor
Soalan: ...berkenalan dengan rational rose...tuturial camne nak design....software guna tool2 nie...
...tahap OOAD saya hanyalah sederhana aje. dan, saya tak pandai ajar OOAD ni. dlm salah satu pekerjaan saya sebelum ini, selama lebih 1 tahun saya cuba ajar 2 developer berkeupayaan yg agak baik, tapi, mereka tak faham2 gak.
walau bagaimanapun, beberapa tip saya:
1. case tool spt rational rose dan together cc, hanyalah tools. kemahiran dlm menggunakan tools ini, mahupun kemahiran dlm uml, tidak sedikitpun menjamin kemahiran dlm OOAD.
2. seorang yg mahir dlm OOAD, mampu buat design yg dasat walaupun dgn white board (lebih baik ialah electronic whiteboard, boleh print, tak yah salin), mahupun dgn kertas dan pensil aje.
3. ROI (return on investment) yg maximum utk sesuatu case yg mahal spt rational rose / together cc, ialah apabila sw designer tu, sudah agak mahir dlm OOAD. maka, kemahiran dlm uml dan case tool tersebut menjadi skill sokongan kpd skill utama sw designer iaitu kemahiran OOAD. dikala ini, syarikat mendapat pulangan maksimum atas pelaburan mereka dlm membeli case tool.
4. seorang yg baru nak belajar buat sw design menggunakan OOAD dgn notation uml, di masa yg sama nak guna case tool yg sememangnya agak komplek spt rational rose dan together cc, mungkin menghadapi rintangan yg lebih besar berbanding seorang yg fokus kpd hanya OOAD dan minimal uml, di atas kertas / white board.
5. sekiranya, approach yg terpaksa dilalui ialah bukan dgn menguasai OOAD dulu, tapi menguasai case tool dan uml (ini yg paling kerap berlaku), maka, harapan saya, fahamlah situasai sebenar iaitu uml case tool tidak menjamin design yg baik. anda sebagai sw designer la yg perlu bekerja keras utk hasilkan design yg baik. sambil2 belajar uml case tool, berusaha keraslah utk kuasai OOAD. semoga berjaya.
Soalan: ...bahan rujukan ape dalam OOAD nie...
saya cuba belajar OOAD sekitar tahun 96-97 dulu. masa tu masih guna vb. pi kursus dan beli buku, bahkan beli training CD mamat bernama peter coad sekali. kantul. berpindah ke java yg dikhabarkan lebih oop dpd vb. pun kantul. rasa frust betul. dah lebih 1 tahun belajar OO, tapi masih terkial2 spt:
- ok selepas step ini, nak kena buat apa plak yek?
- betul ke apa yg aku buat ni? spt dlm buku ke, atau syok sendiri? tapi... macam tak betul aje.
- ok, aku dah buat spt dlm buku. rasanya dah betul, tapi sekarang apa plak. dan, mana faedah yg dijanjikan oleh OO ni? tak nampak pun? mana dia janji2 manis mu? penat lelah buat dan pecah kepala, tak dpt pun saya merasai dan menikmati faedah OO yg digembar gemburkan? aku tertipu ka???!!!!
alhamdulillah, syarikat tempat saya kerja ambil seorang OO consultant/mentor. orang tempatan. dia buat OOAD dlm satu projek bersama2 dgn saya. dia guide saya spt semasa go thru user requirements, dia guna use case dan activiti CRC. dlm bulan pertama, lampu dlm kepala saya di'on'kan. alhamdulillah. lepas itu, bahan2 yg saya telah lama beli spt buku dan training CD, membawa makna kpd saya. walaupun tak terus faham, tapi, bila lampu itu di'on'kan, ia ibarat kunci kpd ilmu OOAD yg terpendam dlm buku2 dan pelbagai bahan lagi.
cara yg sama saya cuba dgn kedua2 'apprentice' saya tu, tapi saya gagal.
ringkasnya, saya guna OO mentor utk belajar OOAD ini.
Tambahan chatid kpd jawapan saya dgn menyenaraikan buku2 yg beliau gunakan, menyedarkan saya yg saya ni dah membebel lebih2 plak, tapi tak benar2 jawap soalan. So, saya tambah lagi dgn jawapan tentang buku yg saya guna. Masalahnya, diri ini masih bersemangat lagi nak kongsi pengalaman, akibatnya, membebel lagi...
Kalau buku, yg saya suka antaranya (selain yg chatid nyatakan):
1. Object Modeling in color by peter coad (faham, hayati dan implement kurang dpd 50% aje, tapi tahap yg saya faham tu, saya rasa dah cukup power dah)
2. Analysis Patterns by Martin Fowler (pun sama kesnya spt no 1)
3. Design Patterns by GoF (faham 70%, hayati 50%, selalu implement 30%)
4. OOA in plain english by tak ingat siapa, tapi tak famous. Yg saya ingat pensyarah universiti ntah negara mana, UK rasanya. Basic OOA, membantu dlm memahami asas object modeling.
Satu perkara penting dlm mengharingi kehidupan sebagai seorang sw designer / architect ialah, keyakinan diri yg munasabah. Tak boleh saya tekankan betapa pentingnya keyakinan diri ini.
Yg dimaksudkan dgn munasabah ialah:
Tahu kelemahan kita dan tahu kekuatan kita. jgn pi terlalu jauh dgn ilmu yg belum pernah diterokai sampai susah atau tak boleh nak patah balik. nanti merana. jgn plak takut mencuba, krn takut mencuba akan membantut horizon kita.
Sekiranya ilmu OOAD yg dicuba gagal, atau tidak memberikan hasil yg memuaskan, lebih baik kembali kpd cara yg biasa kita buat, walaupun tak canggih, krn menghasilkan design / object model hanyalah satu bhgn, coding dan maintenance adalah bhgn yg memerlukan usaha yg jauh lebih besar. Lebih baik back track sekarang and fight another day menggunakan ilmu itu dlm projek lain di masa hadapan.
Resort kembali kpd cara lama krn masa coding dan maintenance kelak, kita lebih yakin disebabkan dah pernah buat dan tahu kelemahannya. Kalau semasa mencuba ilmu OOAD yg baru, dan dah terlajak sampai coding, baru 'sesat', pun saya cadangkan back track semula dan mula sekali lagi dgn cara lama. Cara ini adalah lebih rendah risikonya. Biar terlewat sedikit sekarang, dpd terpaksa mengharungi kepahitan dgn design dan code yg kurang difahami, krn api yg disangka kecil mungkin menjadi besar dikemudian hari dan menimbulkan jauh lebih banyak masalah dan kesusahan.
Pengalaman menggunakan ilmu2 OOAD ini sangat berguna utk projek2 dimasa hadapan.
Utk saya, ilmu OOAD yg paling berharga ialah ilmu OOAD yg saya faham dan hayati, yg berjaya dilakukan dlm projek DAN saya dpt rasakan faedahnya. Ilmu OOAD yg paling dasat sekali pun, oleh guru OO yg paling utama sekali pun, tapi, kalau saya tak dpt kuasai, tak faham dan tak yakin masa mencubanya, serta tak dpt merasakan faedahnya, adalah kurang berguna kpd saya.
Dan, fahamlah, so called guru2 OO ni pun mengakui, bhw ilmu2 OOAD berkembang dari masa ke semasa. As time goes on, as more experience diperolehi melalui applying ilmu tersebut dlm projek, ilmu itu sendiri melalui pelbagai bentuk perubahan dan penambahan. Cthnya artikel di ibm developerworks tentang masa depan Use case oleh Ivar Jacobson, pengasas Use case itu sendiri. Maaf, lupa link.
Maksud semua ini ialah, ilmu OO tak statik. Ia sentiasa melalui proses continuous improvement, dari masa ke semasa, mengikut pengalaman yg dilalui oleh practitioner. Oleh itu, kenapa mesti kita ambil bulat2 ilmu ini, walhal ia mungkin berubah lagi dan lagi. Kalau kita sendiri merasakan, semasa applying ilmu tersebut, kita nak ubah sedikit supaya mendapat faedah yg lebih, maka silakan. Jgn takut2. Lakukan krn jika faedah yg diperolehi adalah nyata dan dibukti melalui kejayaannya dlm projek, maka tiada siapa dlm dunia ini yg boleh pertikaikannya.
Inilah keyakinan diri yg saya maksudkan. Yakin utk terokai jln baru, variasi baru. Berani utk keluar dpd landasan yg telah ditetapkan oleh ilmu OO kini. Krn, kayu pengukurnya ialah kejayakan kita dlm projek, bukan banyak mana kita ikut isi kandungan buku2 atau artikel2 OOAD. Kita boleh ikut sebiji macam dlm buku2 dan artikel2 ini, tapi projek mungkin kantol gak.
Tak semua yg ada dlm buku2 dan artikel2 itu baik utk kita guna bagi mengharungi projek kini. Gunalah berpada2, mana2 yg ngam betul dgn kita, gunalah lagi di projek lain. Mana2 yg kantol dgn kita, cepat2 buang dpd projek kini, utk dicuba semula dikemudian hari, di projek yg lain. Mungkin masa kesesuaian belum tiba dan ia mungkin mendatangkan lebih banyak mudharat dpd kebaikan jika diteruskan dlm projek kini.
Yg dimaksudkan dgn kantol ialah, design dan/atau code yg dihasilkan tidak difahami, lebih kpd teragak2, "betul ke ni...?". Usahlah percaya bulat2. Usahlah meletakkan kepercayaan membabi buta walaupun ilmu OO yg dicuba itu dpd maha guru OO. Saya tak menyatakan ia tak berguna. Hanya, mungkin keadaan dan situasi, mungkin tahap dan keupayaan kita belum sampai lagi.
Ini semua pendapat saya aje. Lain orang, lain cara dan keselesaannya. Itu tak salah, bahkan amat sihat krn ia memperkayakan style dunia sw dev.
Soalan: ...berkenalan dengan rational rose...tuturial camne nak design....software guna tool2 nie...
...tahap OOAD saya hanyalah sederhana aje. dan, saya tak pandai ajar OOAD ni. dlm salah satu pekerjaan saya sebelum ini, selama lebih 1 tahun saya cuba ajar 2 developer berkeupayaan yg agak baik, tapi, mereka tak faham2 gak.
walau bagaimanapun, beberapa tip saya:
1. case tool spt rational rose dan together cc, hanyalah tools. kemahiran dlm menggunakan tools ini, mahupun kemahiran dlm uml, tidak sedikitpun menjamin kemahiran dlm OOAD.
2. seorang yg mahir dlm OOAD, mampu buat design yg dasat walaupun dgn white board (lebih baik ialah electronic whiteboard, boleh print, tak yah salin), mahupun dgn kertas dan pensil aje.
3. ROI (return on investment) yg maximum utk sesuatu case yg mahal spt rational rose / together cc, ialah apabila sw designer tu, sudah agak mahir dlm OOAD. maka, kemahiran dlm uml dan case tool tersebut menjadi skill sokongan kpd skill utama sw designer iaitu kemahiran OOAD. dikala ini, syarikat mendapat pulangan maksimum atas pelaburan mereka dlm membeli case tool.
4. seorang yg baru nak belajar buat sw design menggunakan OOAD dgn notation uml, di masa yg sama nak guna case tool yg sememangnya agak komplek spt rational rose dan together cc, mungkin menghadapi rintangan yg lebih besar berbanding seorang yg fokus kpd hanya OOAD dan minimal uml, di atas kertas / white board.
5. sekiranya, approach yg terpaksa dilalui ialah bukan dgn menguasai OOAD dulu, tapi menguasai case tool dan uml (ini yg paling kerap berlaku), maka, harapan saya, fahamlah situasai sebenar iaitu uml case tool tidak menjamin design yg baik. anda sebagai sw designer la yg perlu bekerja keras utk hasilkan design yg baik. sambil2 belajar uml case tool, berusaha keraslah utk kuasai OOAD. semoga berjaya.
Soalan: ...bahan rujukan ape dalam OOAD nie...
saya cuba belajar OOAD sekitar tahun 96-97 dulu. masa tu masih guna vb. pi kursus dan beli buku, bahkan beli training CD mamat bernama peter coad sekali. kantul. berpindah ke java yg dikhabarkan lebih oop dpd vb. pun kantul. rasa frust betul. dah lebih 1 tahun belajar OO, tapi masih terkial2 spt:
- ok selepas step ini, nak kena buat apa plak yek?
- betul ke apa yg aku buat ni? spt dlm buku ke, atau syok sendiri? tapi... macam tak betul aje.
- ok, aku dah buat spt dlm buku. rasanya dah betul, tapi sekarang apa plak. dan, mana faedah yg dijanjikan oleh OO ni? tak nampak pun? mana dia janji2 manis mu? penat lelah buat dan pecah kepala, tak dpt pun saya merasai dan menikmati faedah OO yg digembar gemburkan? aku tertipu ka???!!!!
alhamdulillah, syarikat tempat saya kerja ambil seorang OO consultant/mentor. orang tempatan. dia buat OOAD dlm satu projek bersama2 dgn saya. dia guide saya spt semasa go thru user requirements, dia guna use case dan activiti CRC. dlm bulan pertama, lampu dlm kepala saya di'on'kan. alhamdulillah. lepas itu, bahan2 yg saya telah lama beli spt buku dan training CD, membawa makna kpd saya. walaupun tak terus faham, tapi, bila lampu itu di'on'kan, ia ibarat kunci kpd ilmu OOAD yg terpendam dlm buku2 dan pelbagai bahan lagi.
cara yg sama saya cuba dgn kedua2 'apprentice' saya tu, tapi saya gagal.
ringkasnya, saya guna OO mentor utk belajar OOAD ini.
Tambahan chatid kpd jawapan saya dgn menyenaraikan buku2 yg beliau gunakan, menyedarkan saya yg saya ni dah membebel lebih2 plak, tapi tak benar2 jawap soalan. So, saya tambah lagi dgn jawapan tentang buku yg saya guna. Masalahnya, diri ini masih bersemangat lagi nak kongsi pengalaman, akibatnya, membebel lagi...
Kalau buku, yg saya suka antaranya (selain yg chatid nyatakan):
1. Object Modeling in color by peter coad (faham, hayati dan implement kurang dpd 50% aje, tapi tahap yg saya faham tu, saya rasa dah cukup power dah)
2. Analysis Patterns by Martin Fowler (pun sama kesnya spt no 1)
3. Design Patterns by GoF (faham 70%, hayati 50%, selalu implement 30%)
4. OOA in plain english by tak ingat siapa, tapi tak famous. Yg saya ingat pensyarah universiti ntah negara mana, UK rasanya. Basic OOA, membantu dlm memahami asas object modeling.
Satu perkara penting dlm mengharingi kehidupan sebagai seorang sw designer / architect ialah, keyakinan diri yg munasabah. Tak boleh saya tekankan betapa pentingnya keyakinan diri ini.
Yg dimaksudkan dgn munasabah ialah:
Tahu kelemahan kita dan tahu kekuatan kita. jgn pi terlalu jauh dgn ilmu yg belum pernah diterokai sampai susah atau tak boleh nak patah balik. nanti merana. jgn plak takut mencuba, krn takut mencuba akan membantut horizon kita.
Sekiranya ilmu OOAD yg dicuba gagal, atau tidak memberikan hasil yg memuaskan, lebih baik kembali kpd cara yg biasa kita buat, walaupun tak canggih, krn menghasilkan design / object model hanyalah satu bhgn, coding dan maintenance adalah bhgn yg memerlukan usaha yg jauh lebih besar. Lebih baik back track sekarang and fight another day menggunakan ilmu itu dlm projek lain di masa hadapan.
Resort kembali kpd cara lama krn masa coding dan maintenance kelak, kita lebih yakin disebabkan dah pernah buat dan tahu kelemahannya. Kalau semasa mencuba ilmu OOAD yg baru, dan dah terlajak sampai coding, baru 'sesat', pun saya cadangkan back track semula dan mula sekali lagi dgn cara lama. Cara ini adalah lebih rendah risikonya. Biar terlewat sedikit sekarang, dpd terpaksa mengharungi kepahitan dgn design dan code yg kurang difahami, krn api yg disangka kecil mungkin menjadi besar dikemudian hari dan menimbulkan jauh lebih banyak masalah dan kesusahan.
Pengalaman menggunakan ilmu2 OOAD ini sangat berguna utk projek2 dimasa hadapan.
Utk saya, ilmu OOAD yg paling berharga ialah ilmu OOAD yg saya faham dan hayati, yg berjaya dilakukan dlm projek DAN saya dpt rasakan faedahnya. Ilmu OOAD yg paling dasat sekali pun, oleh guru OO yg paling utama sekali pun, tapi, kalau saya tak dpt kuasai, tak faham dan tak yakin masa mencubanya, serta tak dpt merasakan faedahnya, adalah kurang berguna kpd saya.
Dan, fahamlah, so called guru2 OO ni pun mengakui, bhw ilmu2 OOAD berkembang dari masa ke semasa. As time goes on, as more experience diperolehi melalui applying ilmu tersebut dlm projek, ilmu itu sendiri melalui pelbagai bentuk perubahan dan penambahan. Cthnya artikel di ibm developerworks tentang masa depan Use case oleh Ivar Jacobson, pengasas Use case itu sendiri. Maaf, lupa link.
Maksud semua ini ialah, ilmu OO tak statik. Ia sentiasa melalui proses continuous improvement, dari masa ke semasa, mengikut pengalaman yg dilalui oleh practitioner. Oleh itu, kenapa mesti kita ambil bulat2 ilmu ini, walhal ia mungkin berubah lagi dan lagi. Kalau kita sendiri merasakan, semasa applying ilmu tersebut, kita nak ubah sedikit supaya mendapat faedah yg lebih, maka silakan. Jgn takut2. Lakukan krn jika faedah yg diperolehi adalah nyata dan dibukti melalui kejayaannya dlm projek, maka tiada siapa dlm dunia ini yg boleh pertikaikannya.
Inilah keyakinan diri yg saya maksudkan. Yakin utk terokai jln baru, variasi baru. Berani utk keluar dpd landasan yg telah ditetapkan oleh ilmu OO kini. Krn, kayu pengukurnya ialah kejayakan kita dlm projek, bukan banyak mana kita ikut isi kandungan buku2 atau artikel2 OOAD. Kita boleh ikut sebiji macam dlm buku2 dan artikel2 ini, tapi projek mungkin kantol gak.
Tak semua yg ada dlm buku2 dan artikel2 itu baik utk kita guna bagi mengharungi projek kini. Gunalah berpada2, mana2 yg ngam betul dgn kita, gunalah lagi di projek lain. Mana2 yg kantol dgn kita, cepat2 buang dpd projek kini, utk dicuba semula dikemudian hari, di projek yg lain. Mungkin masa kesesuaian belum tiba dan ia mungkin mendatangkan lebih banyak mudharat dpd kebaikan jika diteruskan dlm projek kini.
Yg dimaksudkan dgn kantol ialah, design dan/atau code yg dihasilkan tidak difahami, lebih kpd teragak2, "betul ke ni...?". Usahlah percaya bulat2. Usahlah meletakkan kepercayaan membabi buta walaupun ilmu OO yg dicuba itu dpd maha guru OO. Saya tak menyatakan ia tak berguna. Hanya, mungkin keadaan dan situasi, mungkin tahap dan keupayaan kita belum sampai lagi.
Ini semua pendapat saya aje. Lain orang, lain cara dan keselesaannya. Itu tak salah, bahkan amat sihat krn ia memperkayakan style dunia sw dev.
Comments:
Post a Comment
