Thanks, I think you've made some excellent points. I agree with you completely about the need for loose coupling. The tight coupling present in the code is probably one of the reasons it takes so long to debug things. It becomes very hard to make any changes without worrying that you'll break something else.

As I've said before, I don't believe this should be blamed on anyone. It's a natural occurrence with code that's been maintained by several different individuals over a long period of time. Each person has incomplete understanding of the code, and a different coding style. Gradually, coupling between modules gets tighter and tighter. This is why you really need to refactor the code during maintenance, when it's possible.

Many years ago, when I was coding COBOL, long before any books had been written on refactoring, I got chewed out by my boss, because he found out I was completely reorganizing the code I was maintaining. He felt it was a waste of time. I don't know if you have used COBOL, but it is a language that can be abused terribly. There were GOTOs all over the place and tortuous logic. I basically ignored my boss and reorganized the code anyway. I was working as a consultant, and a reporter was doing an article on me. My boss was interviewed. Since he was still angry, he blasted me. Fortunately, the reporter dropped the article. Three years later, my former employer wrote to me to tell me that he'd been wrong and that for the last three years, the code I'd reorganized (refactored in todays language) had been the least troublesome and virtually bug free for the last three years.

I think the answer to my question is that you believe that singltons need to be used carefully, where appropriate, if at all.

I'd like to suggest that, since singletons can be a source of problems, if used improperly, that anyone who plans to use them should try to get another team member to review his/her code. Basically get another pair of eyes on the problem, so you can be really sure you've got a good solution. Does this sound okay?


Christian Foltin wrote:
Hi Ray,

"all kinds of global variables" is exactly the problem. Moreover, you've noticed, that it is very difficult to use the NodeView or MapView for example to display some example nodes in the format menu (an idea, which should be realised, IMHO). One reason for this is, that nearly every class of FreeMind needs all other classes to work - called "tight coupling", AFAIK. 

But the best code originates IMHO from lose couplings - a class needs only itself and a hand ful of helpers that register at instanciation time or later. These helpers are decoupled by interfaces and their implementations. Only with this "ansatz", the software can be tested on module level and parts of the software can be reused. 

I'm going to try to realize more of this decouplings in the future (I've already started, if you look at some of the new dialogs (perhaps the script editor), which can be tested stand-alone).

But a pair that belongs always together is a MapModel and a ModeController. (This answers the last mail of Dimitry). If we have only one ModeController (per mode or globally), the controller is not aware of the model it controls. He is stateless. But then, he isn't able to control the model, as there are states in the controllers (I'm thinking of different states like: node, free node or picture selected, menu states, and if I would have more time, I would think of more). IMHO, there is no advantage (except saving some 200Bytes for each instance of a controller) having only one, because you have that every action of a controller has to ask: to which map do I belong currently? And you have more problems to have parallel controller actions in the background of several nodes currently not displayed in the active map. Well, the mail is long enough now, I think.

Best regards, 


-------- Original-Nachricht --------
Datum: Wed, 28 Nov 2007 11:06:40 -0500
Von: Ray Benjamin <>
Betreff: Re: [Freemind-developer] FreeMind 0.10.0


I confess, I'm also puzzled about your dislike of singletons. Used 
properly, they can be very useful. Do you have objections about their 
use in specific circumstances, or in general? If it's in general, I'm 
interested in understanding why. It's quite possible that I'm behind in 
current thinking about their use, and I'm always interested in learning 

I've certainly seen places where singletons have been abused, which can 
lead to big problems, since some people treat them as permission to 
establish all kinds of essentially global variables. I've found them to 
be pretty useful, as long as I only used them where they fit the problem 
I was trying to solve.


Dimitry Polivaev wrote:
Hi Chris,

first of all, when I write "singletons" I mean that we do not need 
multiple instances of the mode controllers with corresponding actions 
and listeners. It does not mean that the classes should implement the 
singleton pattern. But I do not see any preferences of creating all 
those objects each time we create a new map view or load a new map.

Further I have read that you do not like the singletons. But I still do 
not see what you find wrong about them. I have to admit that I can not 
follow you and understand you properly because you neither explain what 
you mean nor tell me any arguments. I am even not sure, whether you 
think that we need many controller instances and what reasons you could 
have for it. So if you want that I understand you and come to you, you 
could write a bit more.

Your appeal to read "good literature" does not make your position any 
bit clearer either. But if you like to recommend me some good book, you 
can always do it.

Regards, Dimitry

Hi Dimitry,

as I already anounced, I don't support more singletons. Please read
any good literature on MVC pattern and you'll see that none of them
needs any singletons to be successful.

Regards, Chris

This email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
Freemind-developer mailing list