Not your mother’s COBOL

Whenever you start building a new system, there’s a good chance you’re working with customers, clients, employee’s or people of some type or other and our school admin system is no different than any other. It has students, parents, teachers and support staff who are all “persons”. Let’s start with knocking up (I’m Australian, and yes I know what this means in the U.S) a basic person class:

class-id School.Data.Person public.

working-storage section.

01 Person-Id        binary-long              as "Id"             

                    public property with no set.
01 Last-Name        string                   as "LastName"       

                    public property with no set.
01 First-Name       string                   as "FirstName"      

                    public property with no set.
01 Middle-Names     string                   as "MiddleNames"    

                    public property with no set.
01 Person-Title     string                   as "Title"          

                    public property with no set.
01 Birth-Date       type DateTime            as "BirthDate"      

                    public property with no set.
01 Person-Address   type School.Data.Address as "Address"        

                    public property with no set.

method-id new public.
local-storage section.
procedure division using by value   personId      as binary-long
                                    lastName      as string
                                    firstName     as string
                                    middleNames   as string
                                    personTitle   as string
                                    birthDate     as type DateTime
                                    personAddress as type 

                                                  School.Data.Address.
                                    
    Set Person-Id       to personId.    
    Set Last-Name       to lastName.    
    Set First-Name      to firstName.   
    Set Middle-Names    to middleNames. 
    Set Person-Title    to personTitle. 
    Set Birth-Date      to birthDate.   
    Set Person-Address  to personAddress. 

    goback.
    
end method.

method-id ToString override.

procedure division returning returnString as string.

Set returnString to String::Concat(Last-Name::ToUpper() ", 

                                  " First-Name " " Middle-Names)

end method.

end class.

Looks a bit different to the COBOL you learnt from Mum, doesn’t it?

I’m not going to go into huge detail on object-oriented theory and what it means in the COBOL world … Encapsulation, inheritance, polymorphism, blah, blah, blah! We want to get coding and develop a little understanding on the way. You can then extend your understanding by doing a little homework.

That being said, you need to understand that in the .NET world classes are like factories that create things: objects (sometimes referred to as types). There are special classes called static classes where this is not quite true, but we’ll cover this later. Objects are constructed of other objects which you might think of as like data. The special thing about objects is, however they have built in behaviour that is invoked when the object is sent a message. In the .NET world messages are sent to methods. So in the above example the Person class creates Person objects. Each person object contains some data in the form of properties and fields (both visible and invisible to the outside world – we’ll get on to this later). Each object has methods to act on that data (the new method is a special method that is only executed once on the creation of the object). The currently written methods in the person class are the new method and the ToString method. Classes, data and methods may broadly be private or public (we’ll get to internal and protected later). Public classes, data and methods are visible to all. Private data and methods are only visible to the class in which they are contained. Private classes are only visible to classes in which they are nested.

You’ll notice that I’ve littered the code with this wordy as "Id" statements (in this case Id is a reserved word!). These are the names for the piece of Common Intermediate Language (CIL often shortened to IL) code that will be built into the executable (or assembly). Whilst not strictly necessary if you’re sticking to COBOL code, if you are working in a multi-language project, or if you want to later have other languages access your code, make your public face friendly. By this, I mean:

• no hyphens – they get translated into underscores and just look ugly. Tools like StyleCop don’t like them. This will be hard for you I know!
• use Pascal casing: TheFirstLetterOfEachWordIsUpperCased.
• Try to use full words, unless the abbreviation is common usage: Average instead of Av, Date instead of Dte. You aren’t saving typing – the IDE does most of this for you in this environment.
• Do not imbed the class name in the field/property/method name. In this case it is Id not PersonId, Title not PersonTitle. It all becomes superfluous and more readable when you start using the item.

You’ll notice that this class contains several public properties. We’ll get on to this in the next post. Just, let me tell you though, properties are a Good Idea. Perhaps one of the best ideas in .NET …