Depiction of program declaring a variable and then assigning it a value

Transcription

1 Programming languages I have found, the easiest first computer language to learn is VBA, the macro programming language provided with Microsoft Office. All examples below, will All modern programming languages contain common common features. They are: Statements Loops Branching Variables Procedures Statements Programs execute in a logical order. For example, if we want our -program to do ten things, we will write ten statements. When the program executes it will execute the statements from the first to the last one in the order they are written. In the example below, what will the value of the variable sum be after all statements have executed? Loops Programs are always looping for one reason or another. There are various types of loops. While Loop - Loop while a condition is true. Repeat Until Loop - Loop until a condition is true For Loop - Loop for a specified amount of times. Below are examples of two loop types. What do you think the value of Count will be after all lines have executed? What about the value of i?

2 Flow Control Branching is when we make a decision as to which path the program should proceed with. Usually this decision is binary and the decision is based on evaluating a Boolean expression. Other times there are multiple paths and the condition is non Boolean. A Boolean expression, is any expression that has a true/false value. For example, Are you an American Citizen?, is either true or false. For example, What Country are you a Citizen of?, has multiple responses. See example below.

3 Variables Variables hold data while it is manipulated. Physically a variable is a pointer to an area of computer memory where the data is stored. So, for example, when I declare an integer variable, I am actually reserving a small portion of computer memory to store my data. See figure below:

4 Depiction of program declaring a variable and then assigning it a value When we program we ordinarily do not think about what is actually happening on the physical level, just like when we drive a car, we turn the key and trust that whoever designed the car knows what they are doing, and the car will start properly. The same with programming, we think of things as a black box, we don t concern ourselves with how stuff actually works, we just use the features specified by the language and trust that they work. Many beginning programmers, when faced with their first programs crashing, think, Something is wrong with my computer. Invariably they discover that it is a small mistake in syntax or logic that caused the error. Types of Variables The following variable types are common to nearly all languages. When viewed in computer memory, all these variables look alike, a bunch of zeroes and ones. But

5 from the programmer s perspective they are distinctly different types. For example, if you have a numeric variable you cannot assign text to it or you will get an error. Integer Contains the value of a whole number (i.e. 123 not ) Real Contains either whole or fractional numbers (i.e or ) String Contains text. Date Contains any valid date and time. Programmers can take these types and create new types from them. These are the types that come with the language and the programmer can create new ones from them. They can be thought of as Lego blocks from which can be used to create new structures, which in turn can be used to create even more structures. Sometimes, these types are referred to as native types and the structures built from them are called structures or classes. In the example below, we create a data structure called Mortgage which is in turn used as part of a larger data structure called PersonalWealth.

6 Figure 1 System Architecture Before any code can be written, before any language, database, or platform is chosen, every program s basic architecture must be specified. For example, a common architecture is the three tier model. This model, specifies that there are three distinct portions to a program, the Interface layer, the business logic layer, and the database layer. The idea is to separate the different layers, so that one layer can be swapped without affecting other layers. For example, I may have a program that runs on a IPhone and I would like it to run as web page. If I have a three tier program, then I just create a new web page which will communicate with my existing business logic. See diagram below.

7 Three Tier Architecture When dealing with web pages there are special considerations that affect our program architecture. Web programs, by their very nature, are slow. How slow, compared to a non-web application, a million or billion times slower. Think milliseconds versus seconds. Furthermore, because web programs are client server, this means that data will only arrive from the web browser, when asked for. So we compound the latency, or delay between web page and web browser. That is a round trip is required each time we require data. One trip is our data request and one trip is our response from the web server. Below is a web page for Fred Cars. The challenge of this web page is that in order to buy a car, the customer must first enter information in order. Based on the previous pick, new choices appear. For example, the Manufacturer must first be chosen before the Year options are available. Each choice is dependent on the choice before it. We will examine different ways this web page can operate. Some design aspects, not included in this discussion, are, tracking buyer preferences, so we can make suggestions about similar cars the buyer may be interested in, and placing ads to generate extra revenue or promote partner businesses like repair shops or insurance companies. The main aspect we are now concerned with is the speed of our web site. This directly correlates to the number of round trips to the web server that must be

8 made before we can get a price on a car. We will examine three different designs that affect the speed issue. Thin Client or Traditional Client Server - After a model year is chosen, a new request is made to the web server to obtain the Models available for this year. This goes on, until all the buyer requirements are collected, and then the web server returns a page with a seller price. Under this model, there is no business logic on the web page and all the web page does is display the logic that exists on the web server. The web page is quite dumb. Fat Client To speed things up, we need to move processing from the web server to the client. Hence the term, Fat Client. In this case, the web page itself is the Fat Client, in that it does more than just present data sent from the server, it actually has code to present the proper data on its very own. There are basically two ways to handle this. A really fat client will have all possible data it may need when it is first downloaded from the web server. All possible models, manufacturers, years produced, and prices etc.., will be part of the web page. As the user makes his choices, code (JavaScript) will correctly read from the downloaded data and populate the next options the user has to choose from. This model is extremely fast as there is only one round trip to allow the browser to display a price. Thin Client with Ajax This model is a compromise between using a completely Thin Client and a Fat Client. In this model, data is stored on the web server but there is code on the browser to obtain the specific data needed as needed. Rather than submitting the whole web page to the server and receiving a new web page, the browser only requests data that is needed to process the current client request. So after the client chooses a manufacturer, an AJAX call is made to populate the Year combo box. While awaiting for the next combo box to populate, the web page does not freeze as it does with a plain Thin Client.

9 OOP Object Oriented Programming The original method of programming was to have a large amount of code in many different files which would all combine together into one program. It soon became apparent that this method wasn t very practical. This was for two very practical reasons: 1) When changes were made to one part of the program it was very hard to know the full impact of that change, especially if one was working on a large program where many of the original programmers were not around. So changes would be made very infrequently and when they were made, people sort of held their breadth and hoped that nothing had broken. For example, lets imagine I have a heart defibrillator, which has code which tells it to check the heart rate and then if necessary to shock the heart. Let s imagine, I have a variable that called CheckHeartEveryXTimesPerMinute. Suppose, I wish to turn off the heart checking, so I set CheckHeartEveryXTimesPerMinute to 0. But unknown to me, somewhere in the code is a line of code that says TimesPerMinute = 60 / CheckHeartEveryXTimesPerMinute. In other words, I will be dividing by 60

10 by zero. Those familiar with programming will realize that dividing by zero is infinite and that will crash the program! 2) The second impetus for OOP, was the desire to re-use code. When code is one big mush-mash, then it is hard to understand the effects, of re-using a certain parts of the code. Imagine taking a radio from a Russian built car and expecting it to work correctly with an American car. Chances are, the Russian radio expects specific wires and specific voltage. The Russian radio may work in an American car, it may blow up, or it may behave erratically. OOP to the rescue The basic concept of OOP is very simple yet it is very powerful. OOP says that we organize our code, into building blocks or objects that relate to each other. A great example is a spreadsheet. In a spreadsheet, we can view many different objects with each object either containing or contained by other objects. The Workbook object contains the Worksheet objects, which in turn contain the Cell objects which contain the Font objects. Each object, is self-contained. All of its code is within the Object. The Object exposes to the outside, its properties and methods. The Cell object will expose Height and Width properties so that it s container, the spreadsheet, can change its height and width. It will also expose methods like Draw() and Refresh() so that the spreadsheet can display them properly. We can now begin to appreciate OOP. We can change the code within an object, but not the interface with other objects. As long as we don t change what we do, we can change how we do it. Imagine we have a car and we order a new battery for our car. We don t care what chemicals it contains, where it is made, or who made it. All we care is that it has a positive and negative terminal and it gives us electricity when we need it for a couple of years. Since our changes are always within an object, it is easy to see the impact of our changes. It is also easy to test our object to see if it is working correctly. We have to make sure, the exposed portion of our object work as expected. Moreover, since our object is strictly defined as to what it can do, it can be easily be re-used wherever we need the functionality the object can provide. Objects come in all types and forms. We can have mathematical objects, graphical objects, data structure objects, web objects, and so forth. In fact, there are many

11 companies that create objects just for programmers to use in their programs. Nowadays, whenever you open your computer or smartphone, you are looking at a bunch of objects. The Window objects, of course! Object From a Programmers Perspective