CodeGym/Courses/Java Core/Yet another explanation of OOP (loose coupling, tight coh...

Yet another explanation of OOP (loose coupling, tight cohesion)

Available

"Hello, Amigo! I'd like to tell you about another benefit of OOP. You see, programs are more like animals than buildings. They aren't built, they're grown. Development means constant changes. In construction, you can have a good plan and follow it to a T. But in software development, that's not the case."

Quite often, you can't do something in the way you intended to, and you have to rework your program a lot. And even more often, the customer's requirements change.

"But what if the customer provided a really detailed specification?"

"Take a look at what happens over time. If a product succeeds, the customer will want to release a new version, and then another, and another. And, of course, you'll have to make a few «small changes» to the existing product. So software development is a long series of changes. Only the cadence differs. A new version might be released each week, once a month, or every six months."

"So what do we conclude from all this?"

"The product's internal structure must be maintained in a way that will allow major (and minor) changes to be made with minimum reworking."

"How do you do that?"

"We've already talked about how a program consists of objects that interact with one another. Let's use thick dots to represent all of our program's objects on the board. We'll draw arrows from each object (dot) to all of the objects (dots) that it interacts with."

Now let's combine the objects (dots) into groups. Dots belong to the same group if they are a lot more connected to each other than the other dots. If most of a dot's arrows point at dots in its group, then we've group the objects correctly. Dots within the same group are said to be tightly coupled, while dots in different groups are loosely coupled.

This is called the «principle of loose coupling».A program is split into several parts, often layers, whose logic is strongly tied to their internal structure and weakly tied to other layers/parts. Interaction between layers is usually highly compartmentalized. One layer can call another layer using only a small subset of its classes.

"The same 'division of labor' principle, but on a larger scale?"

"Precisely. This allows us to reorganize a department, make it more efficient, and hire even more people, and if we don't change the interdepartmental protocols, then all our changes will be local. Nobody has to be retrained. We don't have to rework the entire system. Each department can optimize its internal affairs in this way if the mechanisms for departmental interaction are chosen well."

"If they're chosen well. And what if they aren't chosen well?"

'Then you'll quickly run out of «wiggle room» for making changes, and have to rework the entire system. That happens from time to time. We can't predict the future, but we can minimize the number of times we have to rewrite the program."

"Okay. I see the benefit of dividing the program like that, but how does OOP come into the picture?"

"When we choose how to structure the departments and how they will interact, we apply the 'principle of abstraction'. In programming, abstraction is used to determine the best way to split up the program and how the parts should interact. This principle can also be applied repeatedly to the constituent parts until we have broken the program down into individual classes."

"And hiding the internal structure of these parts, and strictly limiting how they interact with other parts – that's encapsulation, right?"

"Exactly. Encapsulation and abstraction are cornerstones of OOP. A good program must adhere to these two principles. Later we'll take a look at other principles and come to understand their advantages."

"Good stuff. I can't wait!"

Comments (17)
  • Popular
  • New
  • Old
You must be signed in to leave a comment
11 March 2024, 05:42
Noted
18 August 2023, 00:04
For a better understanding on this concept, I recommend watching this video! https://www.youtube.com/watch?v=uWseUdUqM5U
Hoist
Level 2 , San Diego, United States
4 January 2023, 00:13
catv software programs -- fdma protocol software development pretty brutal --- heading UP the stack
Chandan Thapa
Level 22 , Dubai, United Arab Emirates
9 November 2020, 15:35
had to read it many times.. still not 100% clear but guessing future exercises will make this clearer.
Maxine Hammett
Level 19 , San Diego, United States
27 July 2020, 14:13
I with there were a diagram or image we could see the interaction between objects.
Ruslan Skaldin Java Developer
23 December 2019, 11:47
It would be much better if the lesson provide more illustrations and UML diagrams.
Kent Hervey Software Engineer/Consult Expert
8 April 2020, 01:20
UML
Hoist
Level 2 , San Diego, United States
4 January 2023, 00:11
How much dark matter for that cool badge ; -- that's new
Noam G
Level 15 , Tel Aviv, Israel
18 September 2019, 19:20
As a DevOps engineer there is not enough words to describe the importance of loose coupling principle.
Thomas Sixberry
Level 16 , Rochester Hills, United States
7 February 2020, 15:20
*noted.
Jonaskinny Java Developer at Sandmedia
24 February 2022, 05:11
word !!
Renat Mukhametshin
Level 16 , Pervouralsk, Russain Federation
27 August 2019, 10:34
good!
Ewerton Backend Developer
29 June 2019, 14:20
Should have used some sort of image to illustrate it.
Daniel Buyinza
Level 13 , Kampala, Uganda
25 July 2019, 04:02
Thank you! Was just about to recommend the same. It's really hard to comprehend and visualize the matter.
Fadi Alsaidi
Level 34 , Carrollton, TX, USA
24 December 2019, 16:20
I submitted a request for visual representation of this lesson on everyone's behalf. all commentators, if you realllly want to point an error or request something, use the smiley messaging icon on the right corner of the screen to email CodeGYM team. Otherwise, don't expect them to read all those comments :)
satish
Level 15 , kadapa, India
3 June 2019, 17:03
too crispy
Nikitata
Level 22 , Ba Sing Se, United States
15 July 2020, 11:49
uhhh, what?