The Law of Demeter (LoD)
Law of demeter merupakan style design di oop. Intinya adalah “principle of least knowledge”. Apaan tuh. Mengetahui sesedikit mungkin tentang object yg digunakan di dalam method. Contohnya
public class Project { public void doSomething() { Employee e = new Employee(); ..... } }
jadi kelas project harus mengetahui sesedikit mungkin mengenai kelas employee. Mengetahui apa ? Strukturnya tentu saja. Dengan cara apa emang kita tau struktur employee. Dengan cara kita ngakses property dari employee dan subpartnya. Subpart ini apa maksudnya ? Subpart dari employee. Maksudnya kita ngakses lagi property dari property si employee. Contohnya ….
public class Project { public void doSomething() { Employee e = new Employee(); String cityCode = e.Address.City.Code; } }
Gitu maksudnya. Jadi subpartnya itu City dan diakses lagi Code. Itu ga boleh. Pantang. Haram hukumnya. Najis. Jijik. dll
Jadi gimana yg boleh kita hanya boleh request service dari object employee saja. Tapi kalau kita sudah melangkah jauh. Sampai akses barang2 pribadi dari si employee dan mengobok2nya. Itu pantang. Dan sudah merupakan tidankan asusila. Itu sudah melewati batas. Kita jadi tau terlalu banyak. Ga boleh.
Law of demeter mengatakan bahwa jika kita butuh sesuatu dari subpart dari si object. Maka kita hanya boleh melakukannya melalui object tersebut (via method) dan biarkan object itu sendiri yg menyuruh bagiannya untuk melakukan hal tersebut. Jadi internal terhadap object tersebut. Contoh :
public class Project { public void doSomething() { Employee e = new Employee(); //String cityCode = e.Address.City.Code; String cityCode = e.getCityCode(); // dibungkus di internal si Employee } }
Nah jadi ketergantungan kita tetap hanya pada employee saja.
Jadi apa2 saja yg bisa dilakukan menurut Law of Demeter ??
Jika Object O memiliki method M maka method M tersebut hanya boleh memanggil method/property dari object2 berikut
1. object itu sendiri.
public class Employee { public void DoSomething() { // bla lbla } public void DoEverything() { DoSomething(); // ini boleh. karena masih dalam satu object } }
2. parameter yg dilewatkan.
public class Employee { public void DoEverything(UserAccount acc) { acc.Validate(this); // invoke parameter method } }
3. object yg dicreate oleh si method tersebut
public class Employee { public void DoEverything() { Child child = new Child(); child.Run(); // yah boleh. karena dia yg ciptakan. terserah dia mw disuruh apa. } }
4. instance variable dari kelas O
public class Employee { public void DoEverything(UserAccount acc) { acc.Validate(this); // invoke parameter method } }
Intinya jangan memanggil method yg direturn oleh object lain. Ketika kita mencoba melanggar nya maka jika struktur dari container object berubah maka kita juga akan berubah. Tetapi bila object yg direturn oleh object tersebut bukan merupakan bagian dari container tersebut (dicreate didalam method yg diinvoke) . Maka tidak masalah.
Efek buruk dari LoD adalah banyak sekali method2 wrapper. Tetapi emang sesuatu yg adaptive membutuhkan pengorbanan kan ?? hehhe
hahahaha… betul itu brow.. untuk setiap keperluan yang kita butuhkan, dan jika pun tidak kita butuhkan(bisa aja orang lain yang membutuhkan) kita harus menyediakan method2 tersebut. hahahahaha… klo misalnya ada 2 orang memprogram seperti ini, misalnya aku sama kau bro, kau ajalah yang membuat method2 wrappernya itu ya.. aku tinggal make aja.. hahaha… nice… nice bro…