Tight / Loose Coupling: What's the Idea?

[Alex Stevens]

Well, It's 4:10 on Friday Afternoon and I am now in a state of
turmoil.......

I've just spoken with a trainer (who's opinion would be in far higher regard
than mine), and he's just told me that the way I expected to write an tiered
application is tight-coupled and should be written loosely coupled..........

I am kind of new to multi-tier application programming, although I have good
experience of classes, and objects.

I will attempt to describe my dilemma in the case of a Customer object:

-------Tight Coupled Method-------
I wanted to write a customer class which directly correlated to a customer
table (for ease of description). It would have a CustomerName and a phone
number property. It would have a save method which would write any changed
properties into the database (via a datalayer) and a get method which would
accept a customerID and populate the properties.

In my GUI, to get customer information I would insantiate a customer class
and call the get method passing the customer ID. I could then interogate the
customer properties to the customer name, and populate a text box.
If the user changed the text box, when they click a save button I would
write the textbox value back to the CustomerName property and then call the
save method.

-------Loose Coupled Method-------
The suggested method is to have my customer class, and all data is passed
around using arguments of get and save methods.
The class would have no properties, just a methods: A Get method which has a
(strCustomerName as string) arguement and likewise for the Save method, and
some others for reading (CRUD, Create, Read, Update, Delete....although I'm
sure I don't need to tell you that).

If my customer had even 10 fields this would be cumbersome, then the trainer
said you could pass back an array of values - but then surely this would
have to be order everytime.

In my (limited) mind, I don't understand why the tight coupled method is
bad??

Can somebody clarify this with their opinion on this........?

Thanks

Alex

 

[Tom Leylan]

Well, It's 4:10 on Friday Afternoon and I am now in a state of
turmoil...

I can imagine

I've just spoken with a trainer (who's opinion would be in far higher regard
than mine), and he's just told me that the way I expected to write an tiered
application is tight-coupled and should be written loosely coupled...

From your descriptions I'd have to conclude a) the guy is trying out some
new idea he has come up with or b) you've misinterpreted what he said.

We're all familiar with the term loosely-coupled of course but I've never
heard it applied to the "property" level. One drawback of a generalized,
parameter-based Get/Set is that it is by necessity typeless. It cannot
return a string sometimes and an integer others. This generally makes the
plan "unworkable" because not all data can be represented by a string or any
single data type. The exception would be if it always accepted/returned an
object however.

If my customer had even 10 fields this would be cumbersome, then the trainer
said you could pass back an array of values - but then surely this would
have to be order everytime.

It just sounds plain goofy. If he is proposing something of any real value
he should be able to point to a document somewhere on the Internet that
explains the theory, it's benefits (and importantly) whatever it's downsides
are. All systems have a downside. Have him show you a simple working
example of a system written his way and have him point out the benefits over
having developed it the way you described in your tightly-coupled example.

Tom

 

[ToddT]

yes, i agree with tom. it's ok to be practical.

p.s. who cares what a trainer thinks - there's a reason why he is a
trainer...

 

[Jeremy Cowles]

Alex,

First off, this is a very bad description of tight/loose coupling (from your
trainer). In fact, from the sound of it, your trainer is just starting to
learn OOP, probably from an old source. You can tell this because older
languages have no concept of a "Property", instead you use methods - usually
prefixed with "get_" or "set_" (which is essentially what a property in VB
is). Properties are actually an advancement in language design.

Dependencies are a necessary evil of programming, sure you could make all
variables global, or make them arrays, or whatever hack-of-the-day you want
to use, but the reality is that you are just generating more dependencies on
smaller objects. The idea is to *plan* your dependencies strategically, and
to group them logically - this is called Cohesion, which is a major goal of
any OO design.

Here is a common model for your customer problem (i have added dashes at the
tier boundaries):

----- Data Access:

DataTransport - Reads / Writes data to & from a data source (such as MSSQL
Server) - but never creates an instance of an app domain object (such as a
Customer object).

----- Business Logic:

DataAccessLogicController - Accepts & returns App-domain specific objects
(such as a Customer class), and converts them into commands that
DataTransport will send to your data server. DALC can also combine a group
of SQL commands to preform some sort of logical action on an object. DALC
has no binding to a *specific* data source.

----- Application Domain:

Model / Application Domain Objects - these objects hold your data that has
been loaded from the DALC, they can only hold references to other Model
objects (for example, the Customer can hold an instance of Address, but
never DALC or DataTransport).

----- View / View Logic:

View - the View holds an instance of Model, but never accesses it directly.
Instead, the view depends on either a Controller (see below), or events from
the Model that signal a change.

ViewController - the view controller CAN read & write data directly to the
Model, View, and DALC, but never DataTransport. The ViewController takes
gestures (key-presses, mouse clicks etc...) and converts them into logical
commands based on state.
____________________________

So you could say that the SqlDataTransport is tightly coupled to SQLServer,
DALC is loosely coupled to generic DataTransport (not SqlDataTransport),
View is very loosely coupled to the Model, ViewController is tightly coupled
to View, and Model is not coupled to anything. Now, what is the point of all
this?

1. The Model is re-usable, you can pull the classes out, stick them in a new
project, and everything still works exactly as it did before (which is very
nice if you want to change the UI - i.e.. move the model from WinForms to
Web, or Hand-held devices).

2. The DataTransport can be changed at any time (ie. from SqlServer to MS
Access, or Oracle), and it won't send shock waves through your app. The
only thing effected is the Transport object, not even the DALC will be
effected if you code it right (which is very easy if you use the ADO.NET
Interface objects IDBxxxxx).

3. The Model can change, and the View will suffer limited damage, since the
View only has an indirect dependency.

(and on and on)

You may want to do you self a favor, and go get a book on OOP - "Design
Patterns" is the industry standard book, but it is an extremely hard read if
you are just getting into OOP. It sounds like your trainer may need one too.
An easy start may be to search for "Model View Controller" or "Model View
Presenter" on google.

Sorry about the long post.

HTH,
Jeremy

 

[Guest]

Hi Alex

I think that what you are asking for, is not well defined with the term Tight/Loose coupling, besides, that term has different interpretations. I think the "idea" your instructor tries to tell, is that a change in your app should have minimal impact in the rest of the system. Thats why we design APIs, interfaces, layers, tiers, servers or whatever, trying to isolate changes impact. And thats the idea in all system design regardless of language (ie OOP, procedural). You should design your system thinking that: you will need to update it as time pass. That restructuring your system to accomodate changes should be easy for you (that is a fast response to your customers). That distributing your updates should be easy, reliable and fast. That your system will have bugs, and your system should alert you so you can track and correct them. That your source code should be clear and documented, so when you need some other programmer to help you, he can do it fast. That, if you are going to design "tiers" that will run in separate machines, you should understand you are designing a server and what that means

I guess I can make the list very long... Welcome to the art of software engineering, system architecting, programming or whatevername this will be called in the next years

Good luck

Mariano.