How do I explain loose coupling and information hi

Question

How do I explain loose coupling and information hiding to a new programmer? I have a programmer who I write designs for, but who can't seem to grasp the concepts of loose coupling and information hiding.

I write designs with everything nicely broken down into classes by function (data access is separate, a class for requests, a controller, about 5 classes total). They come back with a modified design where half the classes inherit from the other half (and there is no "is-a" relationship), and many public variables.

How can I get across the idea that keeping things separate makes it easier to maintain?

Answer 1

Ask him to make a change you know it will be hard because of his design and show him how that would happen using yours.

If he complains, tell him the truth: business will ask more bizarre changes, it's a matter of time he will see that.

Answer 2

I think that OO concepts really need to be learnt practically. One really needs to do these things to understand. I go to school (engineering) and most of my peers don't really get the concept. They know in general that loose coupling is 'good' but not why. They also don't know how to achieve loose coupling. I am working on my final year project now and I got through to them by making them part of the design process. (It helped that they really did understand how and why and had an inkling of its importance)

Given your situation, here is what I would suggest:
1. Make them follow your design exactly (at least for a couple of weeks). If they want to deviate, have them discuss what and why with you. [Time constraints may not permit this].
2. Sit with them on whichever part of the design you are doing next and explain some o0f your design choices to them, with examples. Somethings that are obvious to you may need to be pointed out to them.
3. Be on the lookout for examples, both of good design and bad design and show them how that works better.

The most important task here is of delegation. You have to show them what good code looks like, maybe train them for a couple of hours. Then you agree on when to review and how you can help them (whithin your limited free time (?)) do the task well. The main thing is to get them to identify with and understand good design. Doing these things will help them 'buy-in' to the design. Once they feel it is their design, I am sure they will do better work.

Overall, I think you need to put your foot down and get them to code it right, without stifling their creativity.

I don't really have too much experience in the area. I am just giving my opinion on the subject, based on what worked for me. I hope this helps.

Note
I'd like to add that OO concepts can be learnt from books, while their application can be learnt only by practice. I have added this note in response to a comment by Christopher W. Allen-Poole.

Answer 3

Ask him if it's a good idea to let you borrow $10 by giving his wallet to you for a moment and taking the money yourself.

Answer 4

Programs are systems of interacting parts.

For a system of interacting parts to work together requires connections between these parts.

The more connections, the more costly the program.

For a fixed number of parts, a system whose parts are unnecessarily connected is more costly than a system whose parts are necessarily connected.

Unneccessary connections can only be formed in a system whose parts are unnecessarily exposed to connections from other parts.

Minimising unneccessary exposure of parts to connection from other parts is fundamental to cost-effective program development.

Loose coupling and information hiding are the fundamentals of connection-exposure minimisation.

This is not optional knowledge for a programmer.

This is fundamental.

You cannot be a cost-conscious programmer without this knowledge.

Asking how to explain loose coupling and information hiding to a new programmer is like asking how to explain surgery to a new surgeon? Or to explain architecture to a new architect? Or how to explain flying to a pilot.

If your, 'New programmers,' don't know loose coupling and information hiding, then they are not, 'New programmers;' they are potential programmers.

Curiously, it probably won't help to tell them to read the original two papers: i)Loose coupling: 'Structured design,' by W.P. Stevens, G.J. Myers and L.L. Constantine. ii)Information hiding: http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf

Answer 5

If you do Unit Testing, explain it in terms of test-writing. Alternatively, Abstract Classes and Interfaces both use loose coupling and information hiding to great effect. If you explain it to him in terms of other concepts he may already have a handle on, he'll be more likely to appreciate the concept quickly.

Answer 6

Just like the move from 16 bit to 32 bit windows applications where processes were given their own address space. This stopped any other process from being able to kill your application when it "accidently" walked over your data.

Moving processes to different address spaces was like treating each process as a class, and hiding the memory internally and decoupling the processes by forcing interprocess communication to only happen via an expected interface ( eg Windows Messages ).