posted 12 years ago
One more thing I want to add about the StudentRecord example is that I have an assumption that the database is synchronized for concurrent access. No two DB admins can access them at the same time.
This may not be a good example. But I want to demonstrate about the degree of coupling. The degree of coupling ranges from tighly couple to loosely couple. There are some software metrics to calculate the degree of coupling. Software metric is not in the exam , and it is another expert's topic.
In the example, I just want to demonstrate the simple aspects about tighly coupling and loosely coupling. This is not a perfect example.
If you, as one of the DB admin, use a piece of application code to access student's record by using p.Name and save the name in a variable for your further development, your application code must be tightly coupled to the student record. Chances are good that the student's name will be updated and your application code is still using the old name.
One the other hand, if you, use a piece of applcation code that accesses student's record by using p.getName() , your application code's degree of coupling to the student record is decreased. Your application code does not care what p's name is. Your application code access the student record through its API only, not directly access its data.
When a piece of code is developed, it should know other objects' encapsulated data as little as possible. Sometimes, a well encapsulated code supports loose coupling even though encapsulation and loose coupling are two different unrelated OO principles.
Again, this is not a perfect example. But the major issue you will be tested is loosely coupling will have less bad effect on your code, according to KB's practice exam.