OOD: Dependency between classes…
Hal lain yang perlu diperhatikan saat design adalah ketergantungan sebuah kelas terhadap kelas lainnya. Idealnya, ketergantungan dibuat seminimal mungkin agar modifikasi di sebuah kelas tidak terlalu besar pengaruhnya terhadap kelas lain.
Ketergantungan (dependency) kelas B terhadap kelas A dinyatakan dengan visibility kelas A terhadap kelas B. Ada beberapa jenis visibility (diambil dari definisi RUP), yaitu:
- global visibility; biasanya untuk kelas-kelas utility; kelas utility A visible terhadap B apabila instans kelas B bisa menggunakan seluruh service dari kelas A; apabila kelas A dimodifikasi, maka kelas B perlu dimodifikasi pula di bagian-bagian yang memanfaatkan service kelas A.
- parameter visibility; kelas A parameter visible terhadap kelas B jika method kelas B punya parameter bertipe kelas A. Jika kelas A dimodifikasi, maka hanya method terkait saja yang mungkin harus dimofifikasi di kelas B.
- field visibility; kelas A field visible terhadap kelas B jika kelas A di-create dan di-invoke oleh kelas B; visibility jenis ini digambarkan sebagai asosiasi (bukan dependensi)
- local visibility; kelas A local visible terhadap kelas B jika service kelas A hanya diperlukan pada suatu method di kelas B; ketergantungan kelas B terhadap kelas A hanya ada di method tsb.
Dependency digambarkan dengan garis putus-putus dan arah panah terhadap kelas yang menyediakan service (kelas A pada contoh-contoh di atas).
Buat apa lagi ini ? Tentu saja untuk memperkirakan efek modifikasi sebuah kelas terhadap kelas lainnya…
8 Comments »
Leave a comment
-
Archives
- January 2010 (1)
- December 2009 (8)
- November 2009 (5)
- October 2009 (15)
- September 2009 (12)
- August 2009 (5)
- July 2009 (4)
- June 2009 (7)
- May 2009 (14)
- April 2009 (7)
- March 2009 (7)
- February 2009 (18)
-
Categories
- analysis
- aspect oriented
- CBSE
- critical system
- design
- digital learning
- e-business
- ecosystem
- final project
- fun
- health informatics
- introduction
- lecture
- maintenance
- method
- oop
- others
- programming
- project
- project management
- quality
- real time system
- requirement
- research
- service computing
- soa
- software architecture
- software developer
- software metrics
- software process
- software product
- software quality
- software standard
- technology
- testing
- tools
- Uncategorized
- webE
-
RSS
Entries RSS
Comments RSS
Implementasi visibility ini sudah ada di sejumlah bahasa pemrograman atau masih berupa pemanfaatan algoritma saja ya,.
@nanto :
IMHO, bisa sih harusnya, rasanya implementasinya tidak harus terpaku pada fitur bahasa pemrograman
Dalam ranah OO, implementasi konsep visibility ini uda ada sejak jadul bhs pemrogman OO dibuat, misal C++, Object Pascal, dan termasuk Java tentunya. Bgm implementasinya? Persis spt yg bu Yani jelaskan di atas. CMIIW
@Dwinanto:
Ya, dependency ini sudah bisa diimplementasikan. Bahkan mungkin kamu pun sudah sering pakai. Hanya belum familiar bahwa itu adalah dependency…
@Petra:
Ya, asalkan OO language, tentu bisa mengimplementasikannya…
@Irfin:
Benar, konsep ini sudah ada sejak OO dikenalkan. Ada kaitannya dengan konsep enkapsulasi. Hanya saja, visibility yang banyak dikenal kan biasanya untuk atribut dan method (public, private, atau protected). Nah, yang saya bahas di atas adalah visibility kelas…
Coupling pasti akan selalu ada. Tetapi coupling yg berlebihan atau high coupling akan menimbulkan masalah. Oleh karena itu kita harus dapat membagi-bagi nya menjadi modul-modul sehingga coupling tersebut dapat dikurangi.
Ya, sebaiknya suatu kelas dirancang sedemikian rupa sehingga ketergantungannya pada kelas lain, seminimal mungkin..
ketergantungan antar kelas itu dapat diperkecil juga dengan menerapkan whole-part (Pattern Oriented Softaware Architecture vol 1) atau yg lebih concretenya pada prinsip Aggregates Root pada Domain Driven Design
@Welly: thx for sharing…