Lecture 9: Introduction to Objects

Outline

Introduction:
 

Procedural Programming (Review / Overview)

Ideas and Problems Members and Methods Properties Visibility

Object-Oriented Programming (Overview / Comparison)
  

Defining Objects: Classes
When to abandon a GUI-based Approach.

Console Applications

Example: The J_Train Object

Creating the J_Train Class

Procedural Programming

Procedural Programming

Idea: Program is a simple automaton that executes an algorithm:

A step-by-step method for solving instances of a well-defined problem. Linear Structures (Commands) Decision Structures (If…Then Blocks, Select Case Blocks) Iteration (Loops) and Recursion (not yet covered) Compartmentalized Procedures (Functions, Subroutines) Data Structures (Arrays, Structures)

Essential Tools:
    

Advantage: Simple; easy to implement for smaller systems.

Problems:

Weak Coherence: Logical program sub-units not fully modular

Difficult to fully Re-use larger program elements, as a group.

Tight Coupling: Program behaviors and variables not ‘localized’

Code changes can cause subtle, non-local effects to program behavior.

Changes can have strong non-local effects (effects the whole code).

Hard to Maintain (update, etc…)

Object Oriented Programming

Procedural Programming
 

Problems: Complexity, Poor Maintenance, Poor Reusability Solution: Programming using Reusable ‘Black Box’ Modules (Objects)

Object-Oriented Programming

Strong Coherence: Objects should be similar to real-world things!

Real-world things appear as logically-related units, with:
 

Characteristics: Expected appearance Behaviors: Expected input, output, and functionality Proper behavior of each unit can be tested separately. Properly working units can then all be added (like ‘snap-together’ blocks)

Idea: Let’s compartmentalize! Develop large projects in logical units
 

These logical units can easily be re-used, in later projects!

Weak Coupling: Objects should appear as ‘Black Boxes’

With an expected interface to interact with clients (in the code!).

But with other details hidden from ‘clients’. Easy maintenance!

Changes to the inner working of each object can be done independently…

Objects vs. Structures

With Objects, we may combine…
 

Public members, methods, and properties

Note that members may be of different data types…

Private members and methods.

This is a bit similar to Structures, but Objects are a bit different:

First of all, they use a different method of instantiation…

i.e., creation of an instance. To instantiate (make) a new instance , the New keyword is required.

Objects are reference types:

Actually, via a 2-step process of definition + instantiation and assignment.

As we have seen, the Form1 object is made for us, automatically. To make a new Structure instance, New is not required.

Structures are value types:

Ex: We can use the Dim keyword to declare an instance...

This is just like primitive data types (Integer, Double, etc).

Structures and Classes are built in a similar manner…

Using a separate Class File (*.vb), using the Class Keyword.

And making a new instance with the New keyword.

Our First Object: The J-Train

Let’s demonstrate by creating a simple Object…

The JTrain, a simple Train Model

First, let’s think about possible JTrain characteristics/behaviors…

Possible Characteristics (Members or Properties):
    

Color (Perhaps an Enumeration) Length = Number of Train Cars (Integer) Speed = km/hr (Single; positive values mean forward) MainEngine = current identity of the Forward Engine (Integer, etc). TrainState = stopped, waiting, backing, out_of_service (new Enumeration)

Possible Behaviors (Methods):
   

Accelerate/Decelerate (Subroutine) Door Open/Close (Subroutine) Add/Detach a Train Car (Function; returns T/F = successful or unsuccessful) Add/Detach a Train Engine (Function; returns successful or unsuccessful)

Console vs. GUI-based Applications
 

Thus far, we have created GUI-based Applications…

Using WinForms (the Form1 Object). If a GUI is not necessary…

However, a GUI is not always the most appropriate interface:

A GUI can be computationally expensive.

Can be a problem, if the application requires maximum speed . A separate GUI may not be appropriate, for testing or use.

What if we are developing an Object for a larger project ?

If the Target Platform is not capable of displaying a GUI…
 

e.g., Embedded programs Also: applications that will be used via Remote Access.

GUI would be useless ( not be seen by the Remote User ).

In such cases, you may instead choose a Console Application…
 

Which runs directly from a Command Line Interface.

i.e., plain-text display and typing. This module will contain a Main() subroutine which runs automatically…

In this case, we code using a Module instead of a Form Object.

Thus, we will add our executable code to the Main subroutine.

To demonstrate, let’s choose a Console Application…

For our first Object Example: The JTrain!

J-Train Ex.: Creating a Console App.

J-Train Ex.: Creating the JTrain Class

J-Train Ex.: Coding the Interface
• Now, we code the basic User Interface (UI)…

J-Train Ex.: Test Function

Properties (Review from VB.NET 1)

As we noted, Classes are defined to have ‘Members’ …

Class variables that express structure characteristics

We may define and access Public Members directly…

Via the dot ( . ) operator, on a one-to-one basis…with no abstraction. As we did for the JTrain’s State (using the GetStatus() Function)

We can access Private Members using Public Functions/Subroutines…

However, characteristics may also be handled via Properties.
 

These can be used with Members to ABSTRACT-AWAY details.

Or to create composite characteristics and/or secondary effects...

Properties generally come with Get and Set methods.
Public Property prop_Name() As Get_DataType Get ‘method to return the value of Property Statements … End Get Set ‘method to set the value of Property Statements … End Set End Property

The Get and Set methods are both accessed via the DOT OPERATOR.

J-Train Ex.: JTrain Speed

J-Train Ex.: Expand and Test

Conclusion / Forward

In this lecture, we introduced Objects:

And discussed Object-Oriented Programming

Members, Methods, Properties, etc

Defining Objects: Classes

We also introduced Console Applications:
 

And discussed when to abandon a GUI-based Approach. In the context of an Example: The J_Train Class Defining Constructors, which allow:
 

Next Lecture, we continue our discussion of Objects:

Convenient encapsulation of default characteristics. Clients to create new Object instances with specified characteristics. We will learn to create ‘derived Classes’...

A more ‘advanced’ topic: Inheritance

Which inherit, and expand on the characteristics of a Base Class Which inherits from JTrain

Example: The JFreightTrain Class

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.