Tight Code and Tighter Programmers
The other day I was thinking about programs with tight code and loose coupling. Having been raised on tight coding I started looking around for a decent definition of tight code and came across one of my programming heroes, Charles H. Moore, inventor of FORTH programming language. For Moore, as well as others discussing tight code, the term refers to
… a program that is written very efficiently.
That doesn’t say a whole lot, but it says everything. In FORTH, not a single electron is wasted in the code, but not a lot of people use it because you have to think like a processing stack—last in first off. In other words, you have to think exactly backwards from normal sequencing. Ergo, most programmers have migrated to a high level languages with a C++ type of format such as ECMAScript and ActionScript 3.0. To some extent, efficient code is code without superfluous elements that gets a job done. (That’s why I don’t like to use conditional statements where I can help it—there’s generally a more direct option.)
In the context of OOP, I think that tight code can be equated with tightly woven objects. Such objects are good at what they do and nothing else. We can apply the single responsibility rule:
A class should only have a single responsibility.
However, they can work with other objects.
Where we run into trouble with tightness in programming is with Tight Programmers. Their structures are so tight that their objects cannot interact with other objects. Updates? Forget about it! They don’t want updates. In fact if a customer wants an update she’ll be told that she should have thought about that before he wrote all of the code. Is the code tight? Sure, it’s tight. Unfortunately, it is also inflexible. We need to differentiate between tight coding and inflexible coding. Tight coding is lean and purposeful. Inflexible coding resists change and updates. Design Patterns embrace loose coupling and tight coding.
Loose Coupling and Loose Practices
When we used to throw a program together, we called it strong-arming. We basically threw code at a problem until it did what we wanted. Good practices? What practices? We just beat the crap out of it until something happened. That kind of programming is what some consider (politely) as loose coding. In some respects, it’s like programming by committee—anything that works is included in the program. However, the committee is a committee of one—the programmer.
You want change? Hand me that baseball bat and let me fix it right up!
Oddly, loose coupling in programming requires more structure than tight coupling. With tight coupling, you can wrap up a program in a single class that has more lines of code than the national debt. With loose coupling you need to have a well-planned structure so that you can easily know what classes to add and what kind of interface will accomplish a particular task or family of tasks.
The OOP and Design Pattern Programmer has a Split Personality
To be a good programmer in OOP and design patterns, I think you need to have two very different sides of the tight and loose programmer. On the one hand, you need to know your code to write clear, efficient, and effective algorithms. On the other hand, you need to know how to write code that interacts with other code but is not made up of that code.
Perhaps one of the most important elements of Class Diagrams is the set of lines that show the nature of the relationships between classes. These lines represent code within one or both classes that allow them to work together to accomplish a task. More importantly, though, they represent the ability of the structure to encompass change and update without having to rebuild the application. This is accomplished with tight coding of objects and loose coupling.
The Tight Coding and Loose Coupling by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Bill Sanders
Hi William.
Sounds adequate to me. Furthermore it reminds me off a problem I was thinking about lately. How can I build an object relationship in which object B can influence object A without object A having publicly available variables(or getter and setter) – and without pushing all the variables I want object B to influence into object B.
Oh…while writing I were enlighted. I guess if I have to many variables I would want to be infuenced by object B they should be “part” of object B instead of A… isn’t that true?
Hi Mark,
Your last sentence shows the basis of composition. Also, it is one of the basic principles of OOP and Design Patterns–
More commonly, you would probably just use a public property or method in Object A that Object B would use to influence Object A. Check out No New Is Good New for more on relationships in design patterns.
Kindest regards,
Bill
Yes, that’s composition. But I was wondering how I can achieve that without laying out the interface to outta classes. I just want my composition collaborateur work on my object. When I expose the interface by making the methods public everyone else can change the attributes too.
Ah! I see now Mark,
This might do it.
Class A
Class B
private var propertyB:Parent; private function operationB(op:Parent) { this.propertyB=op; }Is that what you had in mind?
Bill
Only in parts.
Lets say class A is a warrior in a game. And class B is a behaviour.
The behaviour class should change a lot of things in the warrior class.(or better instance).
It can only do it by calling the warriors public methods or change variables that have been given to the behaviour class by pushing them into the constructor or any other method.
Thing is I dont want the methods of the warrior class to be public for everyone just for the behaviour class.
Another time when writing about it clears my mind. I could put the warrior and the behaviour in one package and leave them internal so they are only accessable from their own package. Aight?
Hi Mark,
You could do that but I don’t think you need to. In Part II of the Wrong Way Warrior, the Warrior class uses a private method from a concrete Fire class. The Warrior class (interface) has a protected variable fire:Fire.
In the concrete Warrior classes, you see the following:
So while the fireWeapon() method is in a public method in the concrete Fire classes, it is implemented within a private function in the concrete Warrior classes. Keep in mind that fire is inherited from the Warrior class where it holds a reference to the Fire interface.
Since you said that you don’t want the methods of the warrior class to be public, that’s one way to do so.
Take care,
Bill
What i meant was that the fireRifle alters variables of the warrior class without needing the warrior class to provide a public interface. but I see, it’s not possible without passing the variables into a method from the rifle class.
Hi Mark,
I think I understand what you mean but that can’t be done. It can’t be done because in essence you are trying to do this: You are trying to go to the Mall with your car to make some shopping but you want to do all this without ever having to touch the car ( without having to know anything about the car, without having to access it’s “public interface” like “drive(); , stop();, turnLeft();” and so on. ). So, if the car has “no public interface” ( and also, without having a reference to it – “without knowing about it’s existence” ) then you won’t really be able to talk to it, nor will you be able to manipulate it’s properties ( like change it’s tires, turn on the built in Mp3Player and so on ).
Although, maybe using bubbling could somehow achieve what you want but I recommend you avoid bubbling as much as possible ( bubbling would also imply building a really awkward structure so that the event can actually reach that “unknown object” and have it’s “internal listeners” somehow react to the event ).
There is always a much cleaner and less ambiguous solution “out there”, you just need to look for it.
With best regards,
Barni
Barni & Mark,
@Mark–What Barni said.
@Barni–Thanks!
Kindest regards,
Bill
FORTH is not backwards. Non-FORTH is sideways.
Hi Anonymous,
Actually, since FORTH is a LIFO language, it follows the sequence of the stack. Ergo, it would not be backwards. You’re right about that. Not sure why non-FORTH would be sideways, but I’ll take your word for it.
Regards kindest,
Bill