Can any one describe the exact difference between loose coupling and tight coupling in Object oriented paradigm?
相关问题
- how to define constructor for Python's new Nam
- Do the Java Integer and Double objects have unnece
- Keeping track of variable instances
- Object.create() bug?
- std::vector of objects / pointers / smart pointers
相关文章
- 接口B继承接口A,但是又不添加新的方法。这样有什么意义吗?
- Poor Use Case of Object.assign() - Simple Example
- NameError: name 'self' is not defined, eve
- Where is the object browser in visual studio C# 20
- Implementation Strategies for Object Orientation
- An object reference is required for the non-static
- Check if the Type of an Object is inherited from a
- When to use Interfaces in PHP
The way I understand it is, that tightly coupled architecture does not provide a lot of flexibility for change when compared to loosely coupled architecture.
But in case of loosely coupled architectures, message formats or operating platforms or revamping the business logic does not impact the other end. If the system is taken down for a revamp, of course the other end will not be able to access the service for a while but other than that, the unchanged end can resume message exchange as it was before the revamp.
Loose coupling means that the degree of dependency between two components is very low.
Example: GSM SIM
Tight coupling means that the degree of dependency between two components is very high.
Example: CDMA Mobile
It's about classes dependency rate to another ones which is so low in loosely coupled and so high in tightly coupled. To be clear in the service orientation architecture, services are loosely coupled to each other against monolithic which classes dependency to each other is on purpose
In object oriented design, the amount of coupling refers to how much the design of one class depends on the design of another class. In other words, how often do changes in class A force related changes in class B? Tight coupling means the two classes often change together, loose coupling means they are mostly independent. In general, loose coupling is recommended because it's easier to test and maintain.
You may find this paper by Martin Fowler (PDF) helpful.
When two objects are loosely coupled, they can interact but have very little knowledge of each other.
Loosely coupled designs allow us to build flexible OO systems that can handle change.
Observer design pattern is a good example for making classes loosely coupled, you can have a look on it in Wikipedia.
There are certain tools that provide dependency injection through their library, for example in .net we have ninject Library .
If you are going further in java then spring provides this capabilities.
Loosly coupled objects can be made by introducing Interfaces in your code, thats what these sources do.
Say in your code you are writing
now this statement in your method says that you are dependent on
myclass
this is called a tightly coupled. Now you provide some constructor injection , or property injection and instantiating object then it will become loosly coupled.