Hi,
the GUI class is really the class I feel is violating SRP most. I got the feeling it could be split it into, for example:
- UI as highlevel wrapper for Sound, Video, GUI
- SoundUI or similarly named class
- Video wrapper class
- GUI only keeping/wrapping things non-GUI classes need to call
- FontLibrary combining everything font related (also moving most font things from ImageLibrary and ResourceManager there)
- a number of other Utility class(es) only called in gui classes, moved into a suitable subpackage to cut some circular dependencies of other gui classes
- a number of other Utility class(es) only called in gui classes, moved into a suitable subpackage to cut some circular dependencies of other gui classes
- maybe rename/move/reuse the action enums in some gameplay related class
I did not look much at the Controller classes, but you are right that Canvas and MapViewer should also be looked at when refactoring.
Greetings
wintertime
Gesendet: Montag, 09. März 2015 um 14:04 Uhr
Von: "Paolo Bizzarri" <pibi...@gmail.com>
An: win...@genial.ms
Cc: "FreeCol Developers" <freecol-developers@lists.sourceforge.net>
Betreff: Re: [Freecol-developers] The size of dialogs
Von: "Paolo Bizzarri" <pibi...@gmail.com>
An: win...@genial.ms
Cc: "FreeCol Developers" <freecol-developers@lists.sourceforge.net>
Betreff: Re: [Freecol-developers] The size of dialogs
Another, secondary thought on the games code I had was to slowly/continuously cut down on circular dependencies, near emptyforwarding methods and getting it a bit more in line with SOLID, to make it easier to understand going forward.
This is clearly a very good idea. When I worked back in the code the idea was exactly to break those dependencies and arrive to a good state for the GUI part.
The first important point was to hide the GUI from the rest of the code. This has required to create a facade object (GUI class) that was hiding most of the details of the job behind.
Clearly, this required writing forwarding methods, but at least it gave us a first rough separation of what was GUI code and what was controller.
To move forward, we need to solve the circular dependencies between various Canvas, MapViewer and GUI class. To do that, I have done a number of experiments.
The result for me are clear, but the path is going to be a bit slow. We need to make sure that:
- every event is forwarded to the InGameController (including repaint events that are handled now by canvas via repaint, events from the EventHandler, events coming from actions and events on the Mouse)
- the InGameController updates the status of the MapViewer variables (activeUnit, selectedTile and so on)
- the InGameController asks the relevant part of the GUI to update and repaint.
And so on and so fort. Eventually MapViewer will have to be split into:
- a part that is in charge of the state of the GUI (MapState or GUIState) and it will take all the pure setters-getters for the state variables, plus some specific code for manipulating those variables
-a part that is in charge of repainting (MapDrawer). It will take all the chain of methods in charge of painting the various parts of the GUI itself.
Unfortunately, there are lots of places in the GUI code where MapViewer calls Canvas and Canvas calls MapViewer, so it is not that easy.
Eventually, InGameController will grow a little too big, and it will have to be split, but that is for later.
My two cents, naturally.
Paolo
Greetingswintertime
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
