Craig Mattson (Personal Website)
Home - Blog, News, About MePrograms - C#.Net, Java, VB6MusicWebsites

Viewing News Article

Help! I don't understand how to program! (11/06/2009 09:48:48 PM)
Programming - yeah I get it. It's not everyone's cup of tea. It's also not terribly difficult either if you bother to plan your strategies properly. It's not hard to plan, and with a good plan - it becomes an instruction manual. Once you have your instruction manual, you're translating between your plan and the programming language. At the end of it, you have a program. It sounds so simple and so easy, so why do newcomers still find programming a challenge?

Lets face it - if you struggle with programming, when was the last time you actually sat down to plan out properly how you will tackle a program? We have standard ways to represent various abstractions of a program. We don't have them to look busy, or to make some business executive happy - we use them because they help. Granted, for many things I do - I don't need a plan, but as soon as something becomes complex - out comes Visio, NetBeans or just Pen and Paper. Again - I don't do it to look busy, it's merely there to help.

So why don't newcomers do it? Is it they are unaware (unlikely given most good tutorial websites and programming courses discuss Class Diagrams, Sequence Diagrams, Activity Diagrams, Pseudocode etc...) that tools exist to help? Is it considered "stupid" to plan? Is it just simply trying to cut corners and do the bare minimum to pass? I've been trying to work this out for a while - but the clear link between someone who struggles to understand programming and for those that do seems to be at the planning stage.

Over the years, I've worked with people that know the syntax, can write if I give them step by step instructions which suggests they understand the programming language - but getting an idea onto paper seems to be where the problem is. So why is it so?

Lets, for example, take a simple Member Database application. All we really have to do is Create/Read/Update/Delete members and provide a mechanism for doing so. A Member may have a First Name, Surname, Address, Suburb, State, Postcode. So instantly, I can see we need to set up a storage component for Member details, and an application to control the storage component. Class Diagrams (UML) are a good way of representing our objects, methods etc... If you know Class Diagrams, then you would understand the following:

* * * * * * * *

Member
_____________
-firstName : string
-surname : string
-address : string
-suburb : string
-state : State
-postcode : string
_____________
+Member(firstName : string, surname : string, address : string, suburb : string, state : State, postcode : string)
+getFirstName() : string
+getSurname() : string
+getAddress() : string
+Add(member : Member)
+Get(id : int)
+Update(id : int, member : Member)
+Delete(id : int)
+Delete (member : Member)

State
_____________
VIC
NSW
QLD
NT
SA
ACT
WA
TAS

* * * * * * * *


So it's easy to determine our data and methods based on the information above. So what about the methods? This is where Sequence and Activity diagrams shine - but for the purpose of this blog, I'll keep it simple with Pseudocode. I won't go through all methods here, but here's just a few:

getFirstName():

Return the member's first name.

Add(Member):

Add a member to the database

Get(id):

Find a member in the database corresponding to an ID
If member exists then
    return member
else
    return nothing

Update(id, Member):

Find if a member with an ID exists
If member exists then
    update member details in the database
else
    display error message

* * * * * * * *


So once you have your pseudocode down, and your classes drawn up - it's now just a translation process into your favourite language. Whether it be VB, Python, C#, Java etc... the process is simple. Translate the class diagram into a normal class, then for each of the methods - translate the Pseudocode.

If you practice enough, you will find that for smaller tasks you don't even need to plan, or that simply put - you end up coding your classes as if that replaces the need for a class diagram (I will more often do this instead of creating Class Diagrams followed by plenty of refactoring).

If I can be bothered in a future blog post, I'll translate it into various languages - but even a newbie programmer should be able to see how to piece an application together from this.

[Print View]