Chris,
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?
Ray
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,
Chris
-------- Original-Nachricht --------
Datum: Wed, 28 Nov 2007 11:06:40 -0500
Von: Ray Benjamin <[EMAIL PROTECTED]>
An: [email protected]
Betreff: Re: [Freemind-developer] FreeMind 0.10.0
Chris,
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
more.
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.
Thanks,
Ray
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.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freemind-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemind-developer
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Freemind-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemind-developer
