TobiW's Design Study

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m (Second Design)
(Second Design)
Line 45: Line 45:
 
== Second Design ==
 
== Second Design ==
 
After having specified the mistakes I did in my original design I came up with the following improvements:
 
After having specified the mistakes I did in my original design I came up with the following improvements:
# '''Frame''' and '''Service''': Make all attributes and methods that are not accessed by other classes private
+
# Try to apply [[Tell, Don't Ask]] whenever I add methods or functionality to a class
 
# Split '''Frame''' class into
 
# Split '''Frame''' class into
 
#* a class called '''Frame''' which represents only the main window
 
#* a class called '''Frame''' which represents only the main window
Line 51: Line 51:
 
#* a class that handles the menu calls (including creating dialogs)
 
#* a class that handles the menu calls (including creating dialogs)
 
#* a class that encapsulates the config management
 
#* a class that encapsulates the config management
 +
# '''Frame''' and '''Service''': Make all attributes and methods that are not accessed by other classes private
  
 
== Third Design (Final) ==
 
== Third Design (Final) ==
 
Sometime in 4th term ...
 
Sometime in 4th term ...

Revision as of 00:25, 19 August 2009

Contents

Overview

I decided to do the design study on a program I wrote back in Germany before I came here. I wrote it to have a single interface to the many meteorological sites I use to predict and learn something about the weather (mainly for my hobby flying sailplanes). It is quite useable but far from being finished. Technical details: it is written in Python using wxPython for the GUI, and has approx. 2500 lines of code (counted with CLOC).

The project is hosted on sourceforge: [1]

Here's the description I put up on Sourceforge: FreeMet is a meteorological program which provides weather maps, radar movies and forecasts in one GUI. New function can be added easily by writing new plugins which download, parse or process existing data available on the internet.

Design Study Goals

After having done a thorough design study I hope to

  • have good documentation to make it easier for myself and others to start working on the program (again),
  • discover major and minor design flaws,
  • learn all those design patterns and code smells by looking at my code and trying to find them.

First I want to correct some major mistakes I did at my first design (like making too many attributes public). This first stage will only involve the most important classes (the main program class and the plugins). A third design will then incorporate improvements to other design flaws I made. Also, this will be the place to apply some design patterns that are not absolutely necessary but that could make the code more maintainable.

Python

Here, I want to list some Python-specific stuff:

  • A list can store arbitrary values, a set automatically removes duplicates.
  • A dictionary in Python is a Map/HashMap which maps string keys to arbitrary values.
  • __init__() is the class's contructor and __del__() its destructor.

Current Design

  • I included parts of wxPython to illustrate dependencies.
  • The service class implements a plugin architecture

CdFreemet.png

OO Principles and Patterns

  • Service: State (rather than Strategy?)
  • Beware type switches and Avoid downcasting: I've learned from previous projects that controlling the logic with type switches is really bad and almost always leads to unmaintainable code. Therefore the plugin architecture for the services.
  • Don't repeat yourself: there is no unnecessary duplicate code. For instance, functionality that is used by at least two services has been moved up to the Service base class.

Design Flaws

Even before doing a thorough analysis I've discovered several flaws in my design that will need some fixing:

Possible Improvements

Second Design

After having specified the mistakes I did in my original design I came up with the following improvements:

  1. Try to apply Tell, Don't Ask whenever I add methods or functionality to a class
  2. Split Frame class into
    • a class called Frame which represents only the main window
    • a class that represents the central part of the main program (creating components, loading plugins)
    • a class that handles the menu calls (including creating dialogs)
    • a class that encapsulates the config management
  3. Frame and Service: Make all attributes and methods that are not accessed by other classes private

Third Design (Final)

Sometime in 4th term ...

Personal tools