The difference between Tight and Loose Coupling

Introduction

Coupling

Tight Coupling

Loose Coupling

The benefits of Loose Coupling

How to achieve Loose Coupling

A final bonus

References

Comments

Introduction

I have seen a large number of newbie PHP programmers ask the question What is this thing called "coupling"? What is the difference between "Tight" and "Loose" Coupling? What are the advantages or disadvantages of each?. While lots of people have given lots of answers I'm afraid that, in my humble opinion, those answers have tried to say the same thing using different words which can be interpreted in a multitude of different ways. Answers which are imprecise, ambiguous and open to interpretation are as useful as a chocolate teapot, so, in the interests of providing clarity, I shall now provide my own descriptions.

Coupling

As my software engineering efforts are limited to designing and building web-based database applications for businesses (also known as enterprise applications), with PHP as my programming language of choice, for the purposes of this discussion you may assume that for the term "module" I actually mean "object" (something which is instantiated from a class).

Coupling describes how modules interact. The degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between two modules. It signifies a dependency between two modules.

Dependency is a state in which one object uses a function of another object. It is the degree that one component relies on another to perform its responsibilities. If ModuleA calls a method in ModuleB then those two modules are coupled. ModuleA depends on ModuleB while Module B is a dependent of ModuleA. ModuleB is not dependent on ModuleA as there is no call from B to A.

If two modules are coupled the strength of that coupling can range from low/loose/weak to high/tight/strong. Low coupling is better as it tends to create more methods which are polymorphic and therefore reusable via the mechanism known as Dependency Injection. Tight coupling does the opposite by reducing or even eliminating the number of methods which can be reused.

The RADICORE framework is an implementation of the Model-View-Controller design pattern, and the following examples show how a Controller communicates with a Model.

Tight Coupling

Tightly coupled systems tend to exhibit the following developmental characteristics, which are often seen as disadvantages:

1. A change in one module usually forces a ripple effect or chain reaction of changes in other modules.
2. Assembly of modules might require more effort and/or time due to the increased inter-module dependency.
3. A particular module might be harder to reuse and/or test because dependent modules must be included.

In this wikipedia article there is a description of tight coupling:

Content coupling (high)

Content coupling (also known as Pathological coupling) occurs when one module modifies or relies on the internal workings of another module (e.g., accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module.

Here is an example of tight coupling:

<?php 
$dbobject = new Person(); 
$dbobject->setUserID    ( $_POST['userID'   ); 
$dbobject->setEmail     ( $_POST['email'    ); 
$dbobject->setFirstname ( $_POST['firstname'); 
$dbobject->setLastname  ( $_POST['lastname' ); 
$dbobject->setAddress1  ( $_POST['address1' ); 
$dbobject->setAddress2  ( $_POST['address2' ); 
$dbobject->setCity      ( $_POST['city'     ); 
$dbobject->setProvince  ( $_POST['province' ); 
$dbobject->setCountry   ( $_POST['country'  ); 

if ($dbobject->insertPerson($db) !== true) { 
    // do error handling 
} 
?> 

An alternative to this would be to pass each column as a separate argument on the method call like in the following:

$result = $dbobject->insertPerson($_POST['userID'],
                                  $_POST['email'],
                                  $_POST['firstname'],
                                  $_POST['lastname'],
                                  $_POST['address1'],
                                  $_POST['address2'],
                                  $_POST['city'],
                                  $_POST['province'],
                                  $_POST['country'],
                                  );

The above example exhibits tight coupling because of the following:

• The script contains a hard-coded reference to the Model class, in this case it is Person.
• This script calls a method which only exists within the Person object, in this case it is insertPerson
• This script contains references to properties (columns) which only exist with the Person object.
• Should the list of properties ever be changed in the dependent object, then this consumer will need to be updated in order to deal with each of those changes.

For these reasons this particular Controller can only be coupled with the specified Model object. Likewise this Model can only ever be coupled with this particular Controller. There is no possibility of reuse, and this is a Bad Thing ™.

Loose Coupling

Loosely coupled systems tend to exhibit the following developmental characteristics, which are often seen as advantages:

1. A change in one module does not usually force a ripple effect or chain reaction of changes in other modules.
2. Assembly of modules usually does not require more effort and/or time due to the inter-module dependency.
3. The inclusion of dependent modules does not usually make a particular module harder to reuse and/or test.

In this wikipedia article there is a description of loose coupling:

Message coupling (low)

This is the loosest type of coupling. It can be achieved by state decentralization (as in objects) and component communication is done via parameters or message passing.

In the same article it also states

Low coupling refers to a relationship in which one module interacts with another module through a simple and stable interface and does not need to be concerned with the other module's internal implementation.

In this wikipedia article it states:

The degree of loose coupling can be measured by noting the number of changes in data elements that could occur in the sending or receiving systems and determining if the computers would still continue communicating correctly. These changes include items such as:

1. Adding new data elements to messages
2. Changing the order of data elements
3. Changing the names of data elements
4. Changing the structures of data elements
5. Omitting data elements

Here is an example of loose coupling:

<?php  // component script
$table_id = "person";                      // identify the Model
$screen   = 'person.detail.screen.inc';    // identify the View
require 'std.add1.inc';                    // activate the Controller
?> 

<?php  // page controller script for the ADD1 pattern
require_once 'classes/$table_id.class.inc';
$dbobject = new $table_id;
$result = $dbobject->insertRecord($_POST);
if ($dbobject->errors) {
    // do error handling 
}
?> 

The component scripts, page controllers and screen structure (View) scripts are described in more detail in RADICORE - A Development Infrastructure for PHP.

This has the following differences when compared with the tight coupling example:

• The name of the dependent object (Person) is not hard-coded, so this consumer can be re-used with any dependent object which is identified in $table_id.
• The method(s) being called are not specific to the Model, they are generic and inherited from an abstract table class.
• The properties (table columns) within the dependent object are not mentioned by name, so this consumer can be re-used with another dependent with different properties.
• Should the list of properties ever be changed in the dependent object, then this consumer will not need to be updated in order to deal with any of those changes.

Notice that this effect is achieved by splitting the original script into two separate parts:

• A small component script which does nothing but identify which Model, View and Controller components are required to complete this user transaction (use case). There is a separate version of this script for each user transaction in the application which is generated from a function within the Data Dictionary. Each of these is unique and non-reusable. They appear as URLs in the browser's address bar when the application is being run. This method is far better than using a Front Controller.
• A page controller script which calls a pre-set number of methods on the Model(s) which are passed down to it from the component script. There is a separate version of this script for each of the Transaction Patterns which are supported by the framework. All of these Controllers are pre-written and can be reused with any Model

The benefits of Loose Coupling

It is all well and good to say that Loose coupling is better than tight coupling, but without backing this up by explaining the benefits, and proving that you can see the benefits, you can be considered as nothing more than a snake oil salesman.

The benefits of loose coupling can be summed up in two words: Dependency Injection (DI) which is described as follows:

In software engineering, dependency injection is a programming technique in which an object or function receives other objects or functions that it requires, as opposed to creating them internally. Dependency injection aims to separate the concerns of constructing objects and using them, leading to loosely coupled programs. The pattern ensures that an object or function that wants to use a given service should not have to know how to construct those services. Instead, the receiving "client" (object or function) is provided with its dependencies by external code (an "injector"), which it is not aware of

This description was derived from how DI was implemented in the early OO languages, but a more modern language, such as PHP, has fewer artificial restrictions and a greater degree of flexibility. That, coupled with my own ingenuity, allowed me to devise my own unique implementation of DI, which goes as follows:

• The original definition states that the purpose of DI is to separate the concerns of constructing objects and using them. With my technique I am still instantiating a class into an object within the client which is then used within that client, and it is only the identify of that class which is supplied in a variable from an outside source.
• The original definition states that the client should not have to know how to construct those services. With my technique the "how" is no more complicated than using the "new" keyword, or my separate singleton class. None of my table classes requires any external configuring as each has only a single configuration, and that is taken care of by standard code within the class constructor.
• I do not bother with any of the standard methods of injection as I can do what is necessary by loading the class name into a global variable which is then referenced by the controller script which is activated using a simple "require" statement. Easy Peasy Lemon Squeezy.

The statement that Dependency Injection leads to loosely coupled programs is completely wrong. DI does not lead to loosely coupled programs, it follows after modules have been created specifically with loose coupling in mind. DI is impossible without polymorphism which relies on multiple classes sharing identical method signatures. It is more correct to say that Loose coupling leads to dependency injection by following this logical path:

• Dependency Injection requires polymorphism.
• Polymorphism requires identical method signatures in multiple objects.
• Identical method signatures can only be supplied through loose coupling.

It should be obvious that if different objects do similar things but with different method signatures due to tight coupling that there is no polymorphism and therefore no way to inject any dependencies. Quod Erat Demonstrandum.

But how exactly does dependency injection provide something of actual benefit? The answer is: reusability. By providing more modules which can be reused instead of being duplicated it means that you have fewer modules to write, and the less code you have to write to get the job done the quicker that you can get the job done. For example, in an application built using the MVC design pattern in the traditional way every Model requires its own hand-built Controller due to the unique method names - especially the setters and setters for the individual columns - that exist with each Model. In my current ERP application there are over 400 database tables, each of which has its own class, but instead of 400 Controllers which have to be built by hand I have just 45 reusable Controllers which are built into the framework, one for each of my Transaction Patterns. While some programmers still produce a Controller which is responsible for all the use cases which can be applied to their Model - which in my opinion would violate the Single Responsibility Principle - each of my Controllers handles only a single use case. Each of these Patterns performs one or more CRUD operations on one or more tables, but without knowing the identity of these tables. Because of the way I have implemented loose coupling any one of these Controllers can be made to work with any Model, and I use DI - in the form of my component scripts - to identify all the dependent objects required that that Controller.

My ERP application has over 400 database tables and over 4,000 user transactions (use cases), and these are all provided by a library of just 45 Page Controllers. Is there any other framework that can match this level of reusability? Answers on a postcard to ...

How to achieve Loose Coupling

I was able to do this splitting because I ignored common practice in favor of what I considered to be "better" practices which produce code which provides more reusability and therefore more in line with the objectives of OOP. If I have to ignore someone else's idea of "best practice" because it does not produce the best results then I will do so, and anyone who dares to tell me that I am wrong will get the sharp end of my tongue.

• After having decided to create a separate Model class for each database table, and realising that every table was subject to the same set of operations - Create, Read, Update and Delete (CRUD) - I moved all the supporting methods to a generic table class so that they could be shared using inheritance instead of being duplicated. Several years later I discovered that this approach had actually been recommended in the paper Designing Reusable Classes which was published in 1988 by Ralph E. Johnson & Brian Foote.
• While the generic table class contains all the standard boilerplate code which can be used by any concrete table class I sometimes needed a way to insert custom business logic into various points of the processing flow. Because I was already using an abstract table class I found that I could easily implement the Template Method Pattern which then allowed me to insert custom code into any concrete table class by utilising a series of "hook" methods.
• I do not have separate properties in a table class for each of the table columns as there is no rule that says that I should do so, it is just a common convention that nobody questions. I choose not to do it as it requires special code in each calling module to mention those properties by name, and as you can see it produces tight coupling which makes the Controller impossible to reuse with another Model with different properties. When I spotted that the data which can be pushed or pulled into each Model component within the Business layer, either from the $_POST array in the Presentation layer or the table array in the Data Access layer, I did a quick experiment to see if I could pass around all this data in a single $fieldarray argument and found that it did not cause any problems, so that is the approach I adopted. Not only did it not cause any problems, it actually provided enormous benefits.
• By using a single $fieldarray argument to pass data around with my abstract table class it meant that the same code could deal with any amount of data from any database table regardless of the number of columns in those tables. It also meant that every one of my "hook" methods could be coded in the abstract class as follows:

  function _cm_whatever ($fieldarray)
  // interrupt standard processing with custom code
  {
      // customisable code goes here
  
      return $fieldarray;
  } // _cm_whatever
  

  Each of these methods is called by invariant methods within the abstract class, but by default they do absolutely nothing. All the developer has to do is copy the method into his concrete class and insert some customisable code, and at run time this will override the empty method in the abstract class.
• While PHP, being dynamically typed, has never employed strict typing by default, it never required any input data, either from an HTML form or an SQL database, to be correctly typed. All values are scalars and are presented in arrays of strings, and if any internal function requires an argument of a particular type, such as a number, then this is auto-converted (referred to as type juggling) depending on the context. This is exactly how scalars are handled in the C language, and as the original PHP functions were built as wrappers for C functions, they adopted exactly the same behaviour. As all type checking is performed at run time, the minimum way to avoid type errors is to verify that any string which needs to be treated as a number does actually contain a string value that can be converted to a number. While other junior-grade programmers do this by writing their own code I have automated it by creating a standard validation object which is called from within the abstract class. This uses the $fieldarray variable for the values and the $fieldspec array variable for the validation rules.
• Instead of developing each HTML form by hand my previous experience had shown me that different screen layouts contain repeating elements, which is why I decided to use a templating system. I chose XSLT as I was already familiar with it. I originally created a separate XSL stylesheet for each screen, but after some refactoring I discovered a way to create a small library of just 12 reusable XSL stylesheets. The XSL stylesheet handles the layout while the screen structure script identifies which pieces of application data go where on the screen, and with what HTML input control. This then enabled me to create a single standard View object which could create an HTML document for any table in the database.

A final bonus

While building new user transactions (use cases) using all these reusable components I began to see a lot of steps which were repetitive. In other words I saw repeating patterns. This vision enabled me to take the next step which was to write a program to perform all the steps for me as I was becoming too lazy to do them all myself. I based my design on the Application Model which I had encountered in UNIFACE (one of my previous languages), but instead of defining all the table structures in the Application Model first and then exporting them to create the physical database I decided to reverse it by building the application database first and then importing the details into a new Data Dictionary subsystem. I added functions in this subsystem to do the following:

• IMPORT a table's structure into the Data Dictionary using the INFORMATION SCHEMA.
• EDIT the details to supply information which does not exist in the INFORMATION SCHEMA.
• EXPORT the details to create the table class file and the table structure file.
• GENERATE the components for a new user transaction by linking a table with a Transaction Pattern. For each transaction (there may be more than one) this will perform the following steps:
  • Generate the component script.
  • Generate the screen structure script.
  • Add details to the TASK table, and possibly the MENU and NAVIGATION_BUTTON tables.

   

  The developer will then instantly be able to visit that menu in order to select and run that transaction to view and maintain the contents of that table, all without having to write a single line of code - no PHP, no HTML and no SQL. The generated code can be customised, either by modifying the screen structure script to adjust the contents of the screen, or to modify and of the "hook" methods to insert custom business logic.

References

The following articles describe aspects of my framework:

• A Role-Based Access Control (RBAC) system for PHP
• Creating an Audit Log with an online viewing facility
• An activity based Workflow Engine for PHP
• A Data Dictionary for PHP Applications

• RADICORE - A Development Infrastructure for PHP
• User Guide to the Menu and Security (RBAC) System
• User Guide to the Audit Logging System
• User Guide to the Workflow System
• User Guide to the Data Dictionary

• RADICORE Tutorials
• Radicore Videos

• Transaction Patterns for Web Applications
• Reusable XSL Stylesheets and Templates
• The Model-View-Controller (MVC) Design Pattern for PHP
• FAQ on the Radicore Development Infrastructure
• UML diagrams for the Radicore Development Infrastructure
• Internationalisation and the Radicore Development Infrastructure (Part 1)
• Internationalisation and the Radicore Development Infrastructure (Part 2)
• RADICORE for PHP - Functions, Methods and Variables
• The RADICORE Security Model
• RADICORE for PHP - creating PDF output
• What is a framework?
• What is the 3-Tier Architecture?
• Blockchain for Blockheads
• Anatomy of an Enterprise Application
• The Template Method Pattern as a Framework
• How Radicore's Hook System Works
• Evolution of the RADICORE framework
• The Road to Rapid Application Development (RAD)
• OOP practices which save time

The following articles express my heretical views on the topic of OOP:

• Design Patterns - a personal perspective
• Object-Oriented Programming for Heretics
• Design Patterns are dead! Long live Transaction Patterns!
• What is Object Oriented Programming (OOP)?
• Not the three greatest paragraphs ever written on encapsulation
• Table Oriented Programming (TOP)
• A minimalist approach to Object Oriented Programming with PHP
• Using object composition for "has-a" relationships is not such a good idea
• OO Design is incompatible with Database Design
• How NOT to Validate Data
• Object Oriented Database Programming
• Let's Make It More Complicated Than It Really Is Just To Prove How Clever We Are
• What is the difference between Procedural and OO programming?
• The difference between an interface and an abstract class
• Having a separate class for each database table *IS* good OO
• Why I don't do Domain Driven Design
• The concept is OK but your implementation is not
• Re: Objects should be constructed in one go
• Re: What's so great about OOP?
• To There and Back - but still in the wrong place
• Re: Exceptions and talking back to the user
• Are you achieving the aims of OOP?
• Pop Quiz on OOP
• RE: The purpose of inheritance is code reuse
• Fat Model, Skinny Controller
• How to decouple business logic from UI logic
• From Oop to Poop, from Excellent to Excrement
• The database is NOT just an implementation detail
• Active Record: Getting it Right
• The meaning of "abstraction"
• How to Produce a Rich Domain Model with Active Record

These are reasons why I consider some ideas on how to do OOP "properly" to be complete rubbish:

• Case Sensitive Software is EVIL
• Software Patents are EVIL
• Stored Procedures are EVIL
• Object Relational Mappers are EVIL
• Dependency Injection is EVIL
• Not-so-SOLID OO Principles
• I fail to GRASP these principles
• Singletons are NOT evil
• Getters and Setters are EVIL
• Object Interfaces are EVIL
• Object Associations are EVIL
• Inheritance is NOT evil
• Namespaces are for numpties
• Attributes are atrocious
• Autoloaders are abominations
• Composition is a procedural technique for code reuse
• Decoupling is delusional
• Strict typing is for stick-in-the-muds
• Value objects are worthless
• Programmer Productivity takes Precedence over Paradigm Purity
• The Fallacy Of ReUse
• RE: Back to Basics - Three or Four OOP Pillars?
• DTOs are Diabolical
• The true purpose of Dependency Injection

Here are my views on changes to the PHP language and Backwards Compatibility:

• Breaking Backwards Compatibility is EVIL
• Please do not break our language
• BC break in 7.2 caused by undocumented and unauthorised change
• Changing fundamental language behaviors
• Is PHP too verbose?
• RE: Improving PHP's Object Ergonomics
• The PHP core developers are lazy, incompetent idiots
• Is there a case for adding namespaces to PHP core?
• The case against static typing in PHP
• The case against function overloading in PHP

The following are responses to criticisms of my methods:

• What is/is not considered to be good OO programming
• In the world of OOP am I Hero or Heretic?
• Your code is crap!
• On not using the "right" standards
• Your rules are RUBBISH!

Here are some miscellaneous articles:

• Component Design - Large and Complex vs. Small and Simple
• How to handle a Many-to-Many relationship with PHP and MySQL
• A class for validating and formatting dates
• Customising the PHP error handler
• Technical Keys - Their Uses and Abuses
• Pagination - what it is and how to do it
• The Relational Data Model, Normalisation and effective Database Design
• Development Standards - Limitation or Inspiration?
• Saving PHP's Session data to a database
• Are you a Code Monkey?
• The Singleton Design Pattern for PHP
• Working with a stateless protocol
• A flexible method of storing control data
• Web Site vs Web Application
• Using Radicore components in a front-end website
• An end-to-end eCommerce solution requires more than a fancy website
• Database Design - are you Novice, Ninja or Nincompoop?
• Why you should build your web application back-to-front
• Why PHP is not suitable for enterprise grade web applications