Coupling in Application: Afferent and Efferent Coupling

Ada 2 jenis coupling dalam code base : Afferent ( Ca ), Efferent ( Ce ). Anda dapat melihatnya dari perspektif X atau dari perspektif Y.

Afferent Coupling (Ca) adalah apa-apa saja yang bergantung terhadap object tersebut. Atau incoming coupling.

Efferent Coupling (Ce) adalah apa-apa saja yang kita bergantung. Outgoing coupling.

If X depends ke Y atau X => Y maka

X terikat secara efferent ke Y dan Y terikat secara afferent ke X.

Sekarang kita sudah tahu bahwa ada 2 jenis coupling, sekarang kita dapat lebih spesifik dalam hal ini. Nah sekarang kita kembali ke contoh dalam kelas di Object Oriented. Anda diberikan tabel berikut mengenai incoming atau outgoing coupling.

Manakah di antara kelas A, B, C dan D tersebut yang paling loosely coupling. Tentu saja D adalah jawabannya. Dimana tidak ada satupun yang depends ke D dan D tidak depends ke mana pun. Ini adalah kelas yang tidak berguna. :) Karena tidak ada yang menggunakan nya. Seperti usus buntu. :). Lebih baik kelas tersebut di delete saja.

Jadi mana yang lebih baik jika seperti itu ? Anda mungkin dapat menjawab tergantung situasi. :) Hal ini tentu saja valid. Tetapi anda tetap harus mengungkapkan situasi apa yang cocok untuk jenis coupling A, B dan C. Mari kita analisa satu per satu kelas tersebut.

A merupakan self contain dan useful class karena digunakan oleh beberapa kelas atau 5 kelas yang lain. Tetapi jika kita melakukan perubahan terhadap A maka kita kemungkinan akan merusak kelas lain. Contohnya adalah Framework, Serialization code, Logging. DTO atau message transfer object juga masuk ke dalam kategori ini.

B merupakan kelas yang tidak memiliki kelas yang depends ke dirinya, sehingga jika dia berubah, kelas tersebut tidak merusak kelas yang lain. B merupakan kelas yang aman untuk di ubah. Contohnya adalah User Interface.

C merupakan kelas integrasi, business logic/domain atau service layer dimana kelas tersebut tergantung atau memiliki dependensi terhadap kelas domain layer dan dipanggil oleh beberapa client atau lebih. Oleh karena itu hal ini harus di isolasi dan di scope dengan baik. Testability juga menjadi bagian yang sangat penting disni.

Kebanyakan kita akan sangat toleran terhadap incoming coupling terhadap suatu kelas dibandingkan dengan outgoing coupling. Karena dengan outgoing coupling kelas tersebut terlihat melakukan banyak hal dan menyalahi aturan SRP ( Single responsiblity principle ). Kelas tersebut tidak akan stabil dengan kondisi outgoing coupling yang banyak karena terpengaruh banyak hal.

Hal tersebut harus di analisa lebih mendalam lagi apakah kita coupling terhadap kelas yang stabil atau tidak. Karena hal tersebut sangat berpengaruh besar sekali. Contohnya calculation service bakalan sering berubah dibandingkan dengan logging service.

Sekarang bagaimana caranya kita menghitung coupling ?

Contohnya jika kita menghitung coupling dimana satu kelas tergantung ke kelas yang lain hanya dengan 1 method call.

Di sisi lain kelas A memanggil B 3 methods

Outgoing coupling untuk A adalah lebih besar yaitu 3 dalam kasus ini. Sementara untuk X adalah 1. Tapi incoming coupling dari B dan Y adalah sama. Karena jika kita melihat incoming coupling concern kita adalah berapa banyak kelas yang akan terpengaruh jika kita mengubah kelas Y dan B. Jawabannya adalah 1 yaitu kelas A dan X akan terpengaruh.

Jika A lebih banyak lagi melakukan outgoing coupling ke kelas yang lain maka itu mempengaruhi kelas tersebut lebih lagi. Kita juga dapat membuat design guideline untuk membuat developer lebih telaten dalam membuat coupling di codesnya. Bahkan kita dapat melakukan integrasi ke continuous build untuk melakukan static analysis terhadap source code kita.

Satu hal lagi sebelum kita mengakhiri bagian berikut adalah, berhati-hatilah dengan coupling yang tersembunyi. Biasanya coupling tersebut tersembunyi ketika kedua object mengakses resource yang sama atau resource sharing. Resource tersebut biasanya adalah database. Tidak menutup kemungkinan bahwa database tersebut diselimuti oleh REST API. Service A melakukan pembuatan resource dan service lain membaca atau melakukan update terhadap resource tersebut. Tetap saja coupling nya adalah database tersebut. Bisa saja A melakukan call terhadap B secara langsung, tetapi kita membuat database sebagai media couplingnya.

Salah satu rule yang perlu diterapkan adalah membuat coupling eksplisit. Dan membuat data yang di share menjadi seminimal mungkin. Juga kemungkinan hanya sharing ID saja. Dengan membuat coupling ekplisit maka kita dapat dengan mudah menemukan nya dalam source code dan kemungkinan kita juga mendapatkan compile error.

Meskipun hal tersebut tidak dapat di analisa dengan otomatis oleh mesin atau static analysis tools. Oleh karena itu jika anda akan memiliki code base yang besar maka sangat disarankan menggunakan static typing language. Di javascript juga kita dapat menggunakan Typescript untuk melakukan static typing. Sehingga refactoring dan static analysis lainnya akan sangat baik sekali bekerja.