Object Oriented Development

BSA400 – Week 3 Individual Paper

University of Phoenix, Online

Object Oriented Development

When I first started learning how to write code, I had never heard the term “Object Oriented Development”, or even “Object Oriented Modeling.” I’m sure that some form of both of these existed, but they might not have been referred to in exactly those words. Fifteen years of coding later, I was finally indoctrinated in the ways of object oriented development.

The first language that I learned to use was BASIC, which was very simple and easy to learn. There were no objects per se, and the code was pretty much written from the top down. Now that I understand the mechanics of object oriented development, I can see that there were parts of the language that could be considered objects, especially from a design point of view. Even though most of my programs were written from the top down and were executed from the top down, a lot of them incorporated logic that was reused multiple times. Blocks of code that contained that logic could usually be segregated from the rest of the code. Instead of appearing multiple times, these blocks would be written only once, but “called” multiple times.

After BASIC, the next language that I learned was Pascal, named after the seventeenth century French mathematician. Compared to BASIC, Pascal was a much more organized language, with the code separated into actual blocks demarcated with “BEGIN” and “END” statements. Against my instructor’s wishes, as well as popular programming practice, I still coded from the top down. I suppose this would have been an issue if I was entering code on punch cards. Luckily, though, these programs were all on monitors, so I could go back and forth through the document, correcting errors and changing the code where necessary.

After Pascal, I learned a few more languages, slowly realizing that maybe it wasn’t a great idea to always code from the top down. Another bad habit that I was slowly trying to rid myself of was writing code without a design document. A design document can be written in either plain English or pseudo code. With plain English, I would just write out what each part of the program should do, and then translate those concepts into code. Pseudo code is a cross between plain English and full code, using elements of both. Even though it might not be easily readable by someone without a working knowledge of that particular language, a lot of the time it could be figured out fairly quickly.