TobiW's Design Study
From CSSEMediaWiki
(Difference between revisions)
| Line 25: | Line 25: | ||
=== OO Principles and Patterns === | === OO Principles and Patterns === | ||
* '''Service''': [[State]] (rather than [[Strategy]]?) | * '''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 === | === Design Flaws === | ||
Even before doing a thorough analysis I've discovered several flaws in my design that will need some fixing: | Even before doing a thorough analysis I've discovered several flaws in my design that will need some fixing: | ||
| − | * I usually write my programs around one central class which handles most of the logic. This could conflict with [[avoid god classes]] | + | * I usually write my programs around one central class ('''Frame''') which handles most of the logic. This could be a [[large class smell]] and could conflict with [[avoid god classes]] as well as [[separation of concerns]]. Solution: [[Split large classes]], [[Distribute system intelligence]] |
* After learning a lot about the [[Getter and setter policy]], I'm sure I'll be able to eliminate many accessor methods. | * After learning a lot about the [[Getter and setter policy]], I'm sure I'll be able to eliminate many accessor methods. | ||
| + | * Related to getter/setter: some parts apply [[Tell, Don't Ask]] very well, others don't do at all and ask for information all the time. | ||
* Probably because I was too lazy I didn't make all attributes private ([[Information hiding]]). | * Probably because I was too lazy I didn't make all attributes private ([[Information hiding]]). | ||
* Similar to the previous point, there are too many public methods that are only used internally. | * Similar to the previous point, there are too many public methods that are only used internally. | ||
| + | * The '''Service''' base class implements a lot of functionality that is used by all concrete services: [[Avoid concrete base classes]] | ||
=== Possible Improvements === | === Possible Improvements === | ||
* Apply [[Singleton]] pattern to '''Frame''' and '''SplashScreen'''. | * Apply [[Singleton]] pattern to '''Frame''' and '''SplashScreen'''. | ||
Revision as of 08:58, 16 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.
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
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:
- I usually write my programs around one central class (Frame) which handles most of the logic. This could be a large class smell and could conflict with avoid god classes as well as separation of concerns. Solution: Split large classes, Distribute system intelligence
- After learning a lot about the Getter and setter policy, I'm sure I'll be able to eliminate many accessor methods.
- Related to getter/setter: some parts apply Tell, Don't Ask very well, others don't do at all and ask for information all the time.
- Probably because I was too lazy I didn't make all attributes private (Information hiding).
- Similar to the previous point, there are too many public methods that are only used internally.
- The Service base class implements a lot of functionality that is used by all concrete services: Avoid concrete base classes
Possible Improvements
- Apply Singleton pattern to Frame and SplashScreen.
