Measuring Cohesion - The LCOM principle

There has been a constant doubt in my mind since I got to know about the pattern of developing applications based on DDD. Still a novice, I quite frequently come across situations where I'm not sure what the best place to put a particular piece of functionality is. I take a calculated risk, quite often a wrong one, trying to assess the after effects.

I recently came across this great read on cohesion. What should be a "good enough" basis for deciding how cohesive should different pieces of functionalities be. And I particularly loved the example provided:

Considering two different implementations of the same functionality:

Class A{

getDevices()

createDevice()

modifyDevice()

removeDevice()

repairDevice()

diagnoseDevice()

}


It's quite logical to think of all the methods to be directly related to a device. But upon a closer look, one might say that the last two methods only deal with troubleshooting the device. Should the last two methods then sit inside a TroubleShootDevice class?

Depends. Do we think troubleshooting can potentially come up as some sort of a major functionality in our domain? Does troubleshooting involve a lot more than just a device? Then yes. Otherwise it's quite okay to keep it within the same class.

Not saying this is the best approach. There are definitely better approaches out there and a lot more reasoning than just what I said above. But this helps in shaping our decisions. Above all, this is something I personally encounter quite frequently. The LCOM principle is a great aid in determining the level of cohesion in classes.

All credits to Fundamentals of Software Architecture for explaining this in an amazing manner.

Popular posts from this blog

Developmental plasticity

 Back in the days, while in college, all I used to care about was getting it done. Had you shown a white textual output on a completely black screen, you would have done buttery smooth in your academics. I must admit this went on till the final year of my college, until it hit me. I still remember how one of the deciding rounds during my placement was supposed to be something called a "pairing round", one where you'd just bounce off ideas with the mentors and build stuff programatically. What on Earth does 'designing' have to do with programming I thought, until it hit me again! This time, harder! Months long rigorous training around making us understand how the wheels of a car should have nothing to do with the odometer by design. No, we weren't learning automobile engineering, but engineering an automobile in the software ecosystem. It made sense, making sure responsibilities of objects stay right, don't get mixed up and build up a system as self descrip...
Read more

Must vs should

 I've been working with enterprises for the past 4 years, with most of my experience revolving around giants. Extravagant revenue, high stability and the budget to experiment. It's amazing, working on the coolest tech, with comfortable deadlines. As a tech enthusiast, it brings out the best in you, exposing you to state of the art technology which may or may not work in the end. But you can always spike on it, because the enterprises have got the appetite to handle failure in case a long haul doesn't lead to fruitful results. And why shouldn't they? They've grown to such a huge extent that it's now a necessity for them to research, experiment and take corrective measure. Take Amazon for example, the fire phone was a miserable failure but it lead to it becoming a leader in voice assisted tech, alexa. Having spent all my experience in such an ecosystem it was quite evident that anywhere I go I should expect my client to encourage working on tech that's going t...
Read more