Scheduler, Part 2: The Design

During the design phase of any application it’s a good idea to sit down and think about what you’re going to be doing. Jumping in head first will get you results fast, but you’ll often find that you’ve overlooked some aspect of the application and in the end it just makes for a longer and tedious process to actually finish the thing.

The class diagrams for the Scheduler were really simple and straight forward.
The Task class represents a task that we will be scheduling, the task manager contains a list of tasks that and has methods that enables it to control the addition and removal of tasks and the logic to decide which task should be executed next.



The applications Form class is where all the event handlers are taken care of (events are triggered such as clicking on a button). Its good practice to brake your applications logic down into formal steps, in the Scheduler for instance you have to click on the New Task button before the text box below it becomes enabled so that you may enter a name for that task. This makes for more intuitive applications that are more user friendly and have a lower learning curve, an applications interface should always “make sense”.

Keeping control of your programs states and the flow of control is often a tedious task and makes for mindless zombie coding, but once done it really adds to the feel and robustness of the software.

State management and application flow also gives a programmer the opportunity to insure that all the data that is needed for the next step is present, type checking should also be done while controlling program flow.
In my next post Part 3, I’ll go over some code snippets and add a link to the source code and compiled application.