Cohesion tells if responsibilities of element form one thing. That metric is connected with
Single Responsibility Principle or Unix principle:
Do one thing and do it well. If account balance formatter also calculates interest rates and checks the permission to display history, then it has many responsibilities and those are not related to each other. Probably, there should be different components for permission handling or interest rates. On the other hand, if there are multiple components one for integer part, one for floating and one for currency, then anytime programmer wants to display balance, they would need to find all elements. The challenge is to create highly cohesive components.
Coupling is connection or dependency between elements. If changing one element requires changing another element than we say there is tight coupling. If elements are loosely coupled, changing one element does not imply changes in the other. For example, let’s take a look at displaying bank transfer amount. If displaying amount knows how rates are calculated, then anytime internal structure of transfer changes, displaying code also needs to be updated. If we design system to be loosely coupled, based on the interface of an element, then changes to transfer shouldn’t result in changes to the view layer. Loosely coupled components are easier to manage and maintain.