Wednesday, March 03, 2004
AOP
2 article manarik tentang asas AOP yg saya terjumpa dan menemani saya kat dlm train:
Improve modularity with aspect-oriented programming
A look at aspect-oriented programming
OO
Semalam, semasa tunggu train dan sedang membaca tentang list dlm python, saya teringat kembali akan hubungan dlm OO. Baru saya teringat kekeliruan yg saya hadapi sampai la ni, tentang hubungan aggregation dan composition. Kedua2nya adalah hubungan yg lebih kuat dpd association.
Cth composition ialah hubungan badan dgn bhgn badan spt jantung, kepala, dll. Tanpa bhgn badan ini, badan tersebut bukan lagi badan yg sempurna. Tanpa badan, bhgn badan ini pun tak berfungsi. Badan dan bhgn badan saling memerlukan.
Cth aggregation ialah hubungan kereta dgn parts kereta spt enjin, tayar, gear box dll. Tanpa parts ini, kereta bukanlah kereta lagi. Tapi, parts2 ini boleh hidup dgn sendiri. Masih dikira lengkap. Boleh digunakan dlm kereta lain.
Inilah cth aggregation dan composition dan selalunya ia boleh diterima oleh pemikiran saya. TAPI...
Saya berpendapat, ia mestilah ada konteks. Ia mesti bergantung kpd konteks.
Dlm konteks sistem pakar bedah, badan dan bhgn badan bukanlah composition, tapi aggregation! Pakar bedah mampu menyimpan bhgn badan tertentu spt buah pinggang dan masukkan ke dlm orang lain, atau menyimpannya (mungkin) utk orang yg sesuai kelak.
Dlm konteks sistem penjual kereta baru, kereta dan parts kereta bukanlah aggregation, tapi composition! Boleh ke penjual kereta jual kereta yg dah walaupun tanpa wiper cermin kereta? Sudah tentu tidak. Pembeli takkan nak terima walaupun penjual kata "ala encik, satu skru je yg tak de, boleh la..."
Jadi, pendapat saya ialah, usahlah kisah sangat definasi aggregation dan composition ini. Yg penting, kita tahu hubungannya adalah kuat dan mampu mendapat faedah dpd menggunakannya dlm model application kita.
Pendapat saya je.
2 article manarik tentang asas AOP yg saya terjumpa dan menemani saya kat dlm train:
Improve modularity with aspect-oriented programming
A look at aspect-oriented programming
OO
Semalam, semasa tunggu train dan sedang membaca tentang list dlm python, saya teringat kembali akan hubungan dlm OO. Baru saya teringat kekeliruan yg saya hadapi sampai la ni, tentang hubungan aggregation dan composition. Kedua2nya adalah hubungan yg lebih kuat dpd association.
Cth composition ialah hubungan badan dgn bhgn badan spt jantung, kepala, dll. Tanpa bhgn badan ini, badan tersebut bukan lagi badan yg sempurna. Tanpa badan, bhgn badan ini pun tak berfungsi. Badan dan bhgn badan saling memerlukan.
Cth aggregation ialah hubungan kereta dgn parts kereta spt enjin, tayar, gear box dll. Tanpa parts ini, kereta bukanlah kereta lagi. Tapi, parts2 ini boleh hidup dgn sendiri. Masih dikira lengkap. Boleh digunakan dlm kereta lain.
Inilah cth aggregation dan composition dan selalunya ia boleh diterima oleh pemikiran saya. TAPI...
Saya berpendapat, ia mestilah ada konteks. Ia mesti bergantung kpd konteks.
Dlm konteks sistem pakar bedah, badan dan bhgn badan bukanlah composition, tapi aggregation! Pakar bedah mampu menyimpan bhgn badan tertentu spt buah pinggang dan masukkan ke dlm orang lain, atau menyimpannya (mungkin) utk orang yg sesuai kelak.
Dlm konteks sistem penjual kereta baru, kereta dan parts kereta bukanlah aggregation, tapi composition! Boleh ke penjual kereta jual kereta yg dah walaupun tanpa wiper cermin kereta? Sudah tentu tidak. Pembeli takkan nak terima walaupun penjual kata "ala encik, satu skru je yg tak de, boleh la..."
Jadi, pendapat saya ialah, usahlah kisah sangat definasi aggregation dan composition ini. Yg penting, kita tahu hubungannya adalah kuat dan mampu mendapat faedah dpd menggunakannya dlm model application kita.
Pendapat saya je.
Comments:
Post a Comment
