Wednesday, September 22, 2004
Tuesday, September 21, 2004
Lecture 02 Intro - Program Construction Essentials
- Start
- Read in some data
- Do something with it.
- Display a result
- Stop
This is essentially how all programs work (except that they may not stop; instead they return to step 2 after step 4).
In terms of C# this means that we have to know:
- how the program can be made to perform particular operations in sequence
- how the operations are expressed
- how the program can store information that it is going to work on
- how the program can make decisions based on the information it is given
- how the program can display output to the user
These things will be covered in the lecture today.
Monday, September 20, 2004
Tutorial 01 - Decisions Decisions
Friday, September 17, 2004
Practical 01 - Getting a C# Program To Run
Thursday, September 16, 2004
Lecture 01 Notes - The Science of the Happy Ending
- Make sure the customer is prepared (and able) to pay you a good rate for the job.
- Make sure that you understand what the problem is (sometimes the customer doesn't even know this one).
- Make sure that you don't do more work than you need. And you get paid for what you do.
- Make sure that you deliver a product which does the job, can be proved to do the job, and can be maintained over time.
Learning C# is not going to answer all the above points, but it does make a good tool to do the program part. I'm sorry if it seems I'm taking an unduly "product centered" view of the art of programming. But I find that this helps a lot when considering what you should be doing. This part of the course will concentrate on the programming part of the effort. Other parts will worry about specification, testing and the other issues. But you should always keep a clear view of that mythical "happy ending" in whatever you do.
In terms of the business of programming itself, it is worth considering a few terms:
metadata - data about data. Saying "we store the age" is one thing. Saying "we store the age as an integer in years with a low limit of 0 years and an upper limit of 120 years" is much more sensible. The long bit is the data about the data. Or metadata.
abstraction - stepping back from the problem. Before you worry about precisely how the "customer" item will work internally you need to consider just what the customer item will be called upon to do. You can say things like "the customer has an address" and then later you go back and fill in the detail. You need to practice abstraction. Write a program to keep track of a dress shop (and we might do this) and you might think that your starting point is "Dress". It is not. It is "StockItem". If our dress shop starts selling handbags we need a way to handle these later. If we start at the level of dress we are heading for trouble. Start with StockItem and every thing that we want to sell can be handled like this.
program - a sequence of steps which tells something how to do something. This is one way of viewing programming. There are others. We are using this view because we have found it the easiest for people to learn. With this in mind consider:
- shopping list
- address book
- chocolate cake recipe
- CD track list
- club member list
One of these is a program. One of these might be a program. The recipe is the obvious one. It is a sequence of steps. The others are simply collections. Except that when I go shopping I get instructions like "..if you can't get self raising flour then get plain. But then you have to buy some baking powder..." which sound like instructions to me.
