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
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 <raybenjamin@...>
>> An: freemind-developer@...
>> 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 SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> Freemind-developer mailing list