BA 371: Object Orientation

• Kock Ch. 12:  two types of object orientation:
• Object-oriented programming (C++, Java, VB.Net, Smalltalk, etc.).
• Object-oriented analysis & systems design (e.g., Kock, p. 92-95, UML-based design).

• Kock & RR's advice: keep them separate!
• Differences between OOP & nonOOP are vast and well defined:
• OO is built into the language (Class, Inherits, Public, Private, etc.)
• OO and nonOO programs work differently (please ignore Kock's example on page 221):
• e.g., fire brigade codes below (arrays vs. fire fighters).
• e.g., reservoir/river simulation models (systems of equations vs. reservoirs and river reaches).
• e.g., groundwater aquifers: systems of equations vs. pockets of water.

• Differences between OO and nonOO analysis & design are rather tenuous:
• Activity diagrams, data flow diagrams, communication diagrams, class diagrams, etc. can all be considered OO... if we care to!
• We view much of our world as object oriented anyway; i.e., as consisting of
• discrete entities (things) that:
• have attributes that take on values. Hence, the entities have 'state.'
• have behavior; i.e. they go through state transitions.
• can communicate with each other; they can send and receive messages,
• that come in taxonomies (groups & subgroups); and
  

• discrete events that:
• are scheduled to occur at certain times and time intervals.
• or that occur unexpectedly.

• Kock (p. 218): Booch, Rumbaugh, Jacobson, Yourdon et al.: How can we apply the benefits of OOP in the systems analysis and design phase?
• Kock (p.219):  "OO analysis and design approaches have not been very successful because they provide an impoverished view of how information exchanges take place in business processes." --> are the models too parsimonious to have good correspondence?
• RR's theorette: we have always modeled our business processes and their needed support structures as discrete event systems; we just did not call it 'object-oriented.'

• Classes and objects in VB.Net.
• Complex datatypes in VB.Net:

Public Class Point
  Public x_coordinate as Short    
  Public y_coordinate as Short
End Class

Public Class TopLevel

  Shared Sub Main()
    Dim Points(99) as Point
    Dim i as Short

    For i = 0 To 99 Step 1
        Points(i) = New Point()
    Next i

    Points(0).x_coordinate = 100
  End Sub

End Class

• A few things to notice:
• Main() resides inside(!!) a class (TopLevel). This implies that the class has behavior.
• A class gets instantiated to an object once its memory gets allocated through a call to the New() (constructor) function.
• The class TopLevel is never instantiated to an object. It serves only to hold the Main() function. Classes which are not instantiated to objects but which must make available their contents must share (Shared) their contents.
• Notice how, since the Point class and its data members are declared Public, the class TopLevel can access them from its Main() function.
• Had x_coordinate and y_coordinate been Private, the only way for TopLevel to set their values would be to call a Public subroutine on the Point, passing it the desired value and letting it set the value.

Public Class Point
  Private x_coordinate as Short    
  Private y_coordinate as Short

  Public Function GetX() as Short
   return(x_coordinate)
  End Function

  Public Function GetY() as Short
   return(y_coordinate)
  End Function

  Public Sub SetX(ByVal X as Short)
   x_coordinate = X
  End Sub

  Public Sub SetY(ByVal Y as Short)
   y_coordinate = Y
  End Sub

End Class

Public Class TopLevel

  Shared Sub Main()
    Dim Points(99) as Point
    Dim i as Short

    For i = 0 To 99 Step 1
        Points(i) = New Point()
    Next i

    Points(0).setX(100)
  End Sub

End Class

• In OO programs, objects access each other's Public or Protected data or call Public or Protected functions or subroutines on each other (sending messages).

• Suppose that we would like to make a Point in three dimensions; i.e., an XYZPoint that has not only an x_coordinate and a y_coordinate, but also a z_coordinate:
• We could define the class XYZPoint as follows:

Public Class XYZPoint
  Public x_coordinate as Short
  Public y_coordinate as Short
  Public z_coordinate as Short
End Class

• But we could also define the class as a special case of the original class:

Public Class XYZPoint
  Inherits Point
  Public z_coordinate as Short
End Class

• If one now creates an XYZPoint object, the object inherits all attributes and functions from its parent class Point and in addition, has a z_coordinate.

• How to program a simulation of a fire brigade:
• If you have a bucket of water, give it to your neighbor on the left.
• If you have no neighbor on the left, empty the bucket on the fire.
• If you have no neighbor on the right, grab a new (full) bucket, then give it to you neighbor on the left.

• Let's assume that there is an ample supply of buckets, each in reach of the right-most person.
• Let's also assume that buckets are always full (don't have to fill them.)

• Classic (nonOOP) way to program this:
1. Create a boolean bucket that has but one of two values: true (have a bucket) or false (don't have a bucket):
2. Have a buckets array to emulate the fire brigade line. Set all elements to false except for buckets(0).
3. Loop through the array. If the person has a bucket (buckets(i) = true), set it to false and set the next one to true. If the last bucket is true, add it to the fire and set it to false. Always set buckets(0) to true.
4. Repeat 3.

Public Class PaleAndFireLine

  Shared Sub Main()
    Dim buckets(9) As Boolean
    Dim water_dumped As Short = 0
    Dim i, j As Short

    'initialize all buckets to be absent; i.e., nobody has a bucket (not really needed)
    For i = 0 To 9 Step 1
      buckets(i) = False
    Next i

    For i = 1 To 20 Step 1 'simulate 20 buckets to be processed
      
      'update the bucket line
      'do all buckets except the last
      For j = 8 To 0 Step -1 'work backwards!
        If (buckets(j) = True) Then
          buckets(j + 1) = True
          buckets(j) = False
        End IF
      Next j

      'now do the last bucket
      If (buckets(9) = True) Then
        water_dumped = water_dumped + CShort(1)
        buckets(9) = False
      End IF

      'do the first bucket
       buckets(0) = True
      'print out the bucket line
      For j = 0 To 9 Step 1
        If (buckets(j) = True) Then
          System.Console.Write("X")
        Else
          System.Console.Write(".")
        End IF
      Next j

      System.Console.Write("   " + CStr(water_dumped))
      System.Console.WriteLine()
    Next i

  End Sub

End Class

• Notice how we work backwards through the buckets array.

• OO way to program this:
• Create a FireFighter class that has the following information:
• Next neighbor (Short).
• Previous neighbor (Short).
• Absence or presence of a bucket (Boolean).

• Add a subroutine (method) to the FireFighter class so that:
• If a FireFighter has a next neighbor, it passes the bucket to the next neighbor (if it has one).
• If a FireFighter is handed a bucket, it should take it.
• If a FireFighter has a bucket but no left neighbor (last FireFighter in the line), it will add the bucket to the fire.
• If the FireFighter has no right neighbor (first one in the row), it will grab a bucket and give it to the next neighbor.

• Ask the first FireFighter to grab some buckets and watch things happen.
• Note: the following code is rather inelegant and inefficient, but was written/selected to demonstrate/emphasize some key aspects of OOP.

Public Class FireLine
  Public Shared water_dumped As Short = 0
  Public Shared FFers(9) As FireFighter

  Public Shared Sub Main()
    Dim i As Short

    'initialize all firefighters
    For i = 9 To 0 Step -1
      FFers(i) = New FireFighter(i)
    Next i

    'let the first FFer process 20 buckets
    For i = 1 To 20 Step 1
      FFers(0).process_bucket()
      DisplayLine()    
Next i
  End Sub

  Public Shared Sub DisplayLine()
    Dim i As Short

    For i = 0 To 9 Step 1
      If FFers(i).bucket = True Then
        System.Console.Write("X")
      Else
        System.Console.Write(".")
      End IF
    Next i

    System.Console.Write("   " + CStr(water_dumped))
    System.Console.WriteLine()
  End Sub

End Class

Public Class FireFighter
  Private next_neighbor As FireFighter
  Public bucket As Boolean

  'class constructor
  Public Sub New(ByVal number As Short)

    If number < 9 Then 'not last firefighter
      next_neighbor = Fireline.FFers(number + CShort(1))
    End IF

    bucket = False 'not needed but always nice
  End Sub

  Public Sub process_bucket()
    If bucket = True Then 'passing a buck(et)
      If next_neighbor is nothing Then
        FireLine.water_dumped = FireLine.water_dumped + CShort(1)
      Else 'recursively call the next neighbor
        next_neighbor.process_bucket()
      End IF
    Else 'receiving a bucket
      bucket = True
    End IF
  End Sub

End Class

• Some observations:

• The OO approach seems more natural (mimics actors, objects and actions in the real world).
• The OO approach seems less efficient; more activities, more data types, more algorithm.
• Notice that the process_bucket() subroutine is recursive (it calls itself). Note, however, that recursion applies just as well to nonOO approaches.
• In the OO approach classes/objects (structs in C) not only have data types; they also have functions --> objects and classes can not only have data; they can also have behavior.
• Objects and classes can read and write their own data.
• Objects and classes can prevent other objects and classes from accessing their data (Private vs. Public).

• Notice how the bucket attribute of a FireFighter is declared Public so the FireLine class can see it in the DisplayLine() subroutine.
• Notice how the FireFighter objects can call the Public process_bucket() subroutine on other FireFighter objects.
• Objects can be initialized with a constructor:

Public Shared FFers(10) As FireFighter 'declaration

FFers(i) = New FireFighter(i) 'instantiation

Public Sub New(ByVal number As Short) 'initialization
  bucket = False

• Classes can be specializations of more abstract classes through inheritance.

Public Class Foo
  Public var_1 As Short
End Class

Public Class Goo
  Inherits Foo 'weird, but has to sit on separate line 

  Public var_2 As Short
End Class

Public Class MainClass

  Shared Sub Main()
    Dim mine As New Goo()

    mine.var_1 = 10
    mine.var_2 = 20
    System.Console.Write(CStr(mine.var_1) + " " + CStr(mine.var_2))
    System.Console.WriteLine()
  End Sub

End Class

• Classes can inherit from other classes yet implement their own version of parent functions (function overloading).
• Functions and data can be stored and used on a class without ever instantiating an object of that class through the use of the Shared keyword (see our FireLine and System.Console.WriteLine() above and the Hello examples seen in an earlier lab).
• Classes can contain other classes; e.g., System.Console.WriteLine().

• More on VB-OO:

• Take another look at Hello World:

Public Class Hello

  Shared Sub Main()
    System.Console.WriteLine("Hello World...")
  End Sub

End Class

• Hello is the class that contains the Main() function.
• Hello is never instantiated to an object.
• Main() is declared Shared: the subroutine can be called on the class rather than the instance (object) of that class. Similarly, System, System's Console and the Console's WriteLine() method are Shared; no object of those classes has to be created to use/call their methods.
• Question: why would you not just make everything (all classes, their data and their methods Shared)?
• In VB.NET so-called Modules are a special type of class that have their content Shared by definition; e.g.,

Module Hello
  
  Sub Main()
    System.Console.WriteLine("Hello World...")
  End Sub

End Module

• Bottom line: you must(!) work with classes in VB.NET. However, how much you exploit the OO concept is up to you as a programmer.
• VB's Visual capabilities are strongly OOd.