CSC/ECE 517 Fall 2011/ch1 1e sm

This article briefs about how Object-oriented Programming came into being after Structured Programming prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

The Journey of Language Evolution

During the early days of programming language development, assembly languages dealt with code based on machine instructions (operators) that manipulated the contents of memory locations (operands). The level of control and data abstraction achieved was very low. When the first higher-level languages appeared, the operators turned into statements and operands into variables and data structures. These languages consisted of a collection of variables that represented some data and a set of procedures that manipulated those variables. The majority of traditional programming languages supported abstract data types. Thus there is no way to express the commonality between two abstract data types that are similar but not identical, in these languages that support only abstract data types. The object-oriented paradigm went a step ahead by allowing the similarities and differences between abstract data types to be expressed through inheritance, which is a key defining feature of the object-oriented paradigm.

Thus the assembly languages were followed by procedural languages such as FORTRAN, Algol.. Procedural languages were then followed by structured programming languages. Dijkstra, Jacopini and Naur were the forefathers of structured programming. Dijkstra first discovered that modularized, goto-less programs were more efficient. Jacopini drew the conclusion that any program that could be converted to one of the following structures could be considered as a structured program

a) Sequential/Concatenation

b) Alternation/Selection

c) Iteration/Repetition

Dijkstra related the structure of the program text to the structure of the computations. According to him, the flowchart of a program which represents the dynamic execution of the program statements also represents the logic of the text. By relation the logic and the structure, we can understand the working of a program more clearly. Dijsktra’s primitive structures – sequential, if-then statements (similar to alternation) and while-do, repeat-until(similar to iteration) are more or less the same as Jacopini’s base diagrams depicted above. Dijkstra next came up with a general process flow for all programs:

1.Read data
2.Calculate Solution
3.Print Results

These steps are repeated until the program is converted to a form which can be easily compiled and executed. He proposed a “top-down” design to help establish correctness based on a block structured format. Programs with a block structure enabled several programmers to work concurrently and also enabled easier testing and validation

Simula was the first programming language that had objects and classes as central concepts. It was the first language to introduce the concept of class and to allow inheritance to be expressed, and it should be recognized as the “mother” of a few object-oriented programming languages. Besides, because object-oriented concepts have also arisen from the artificial intelligence community, it is not surprising that Lisp has influenced a number of object oriented languages. The prominence of the object-oriented paradigm has influenced the design of other programming languages. There are languages that incorporate object-oriented constructs into the popular C, Pascal and Modula-2, resulting in the hybrid languages Objective-C, C++, ObjectPascal and Modula-3.Other languages influenced basically by Simula and CLU, such as Beta and Eiffel have also appeared and are believed to give good support for the object-oriented paradigm. Although Eiffel and Smalltalk seem to be coherent object-oriented languages with integrated programming environments, C++ has become the most used object-oriented programming language, due to the influence of UNIX and the popularity of the C language from which C++ derived. Finally, Java should look familiar to C and C++ programmers because Java was designed with similar but cleaner constructs; it also provides a more robust library of classes. The dependency graph over time is as shown in the above figure.

Comparison

Debugging

In structured programming debugging of code gets harder as the size of the program increases.

In Object Oriented programming debugging of code is easy as we deal with classes and the readability of the code is improved. The other features that aid in debugging are its Modularity and Independence.

Reusability

Reusability, the ability of software elements to serve for the construction of many different applications, is the main platform of object-oriented programming. Rather than starting from scratch with each new application, a programmer will consult libraries of existing components to see if any are appropriate as starting points for the design of a new application. These components will exist in libraries as class definitions. A programmer will select an appropriate class definition from a library and then create a subclass for the application. The subclass will inherit the methods and properties of the library class, add some new ones of its own and possibly redefine the actions of others. The popularity of OOP stems from the support it gives to a software development process that relies upon pre-existing reusable software components. Reusability is particularly useful for developing graphical user interfaces.

Code Reusability in Structured programming is in the form of subroutines which can be called multiple times. But these can be used only within a single application.

Added benefits of Reusability

Reliability: Components built by specialists in their field are more likely to be designed correctly and reliably. The reuse of these components across many applications will have given the developers of the components ample feedback to deal with any bugs and deficiencies.

Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

Decreased maintenance effort: Using someone else’s components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

Concurrency

As far as concurrency is concerned; objects can be viewed as concurrent agents that interact by message passing, thus emphasizing the role of entities such as actors and servers in the structure of a real-world application. This provides programmers with powerful constructs that allow objects to run concurrently. Concurrency adds the idea of simultaneously executing objects and exploiting parallelism. Languages to which this applies include: Actor, ABCL, POOL-T, Orient84 and ConcurrentSmalltalk.

The way Structured Programs are executed, they degree of concurrency provided is not as much as is provided by Object Oriented Programs.

Focus

Structured programming is based around data structures and functions. Functions are where the actual computation takes place and the data structures hold the data values that the functions act upon and use in their computations.

Object oriented programming, on the other hand, focuses on data. Instead of requiring us to answer questions such as "what we want to do and what do we need to do that", we require to answer questions such as "what kind of things do we want to have and what can those things do for us". Instead of designing our functions first and then coming up with data structures to support them, we design types first and then come up with the operations needed to work with them.

Polymorphism

Polymorphism is the mechanism by which a function can be implemented in different ways. More generically, polymorphism is a programming language feature that allows values of different data types to be handled using a uniform interface.

For example, if we consider a simple drawing program where we have a set of shapes (circles, rectangles, etc.) that share certain things in common (they all have a location, size, and color) but are different in other ways (how they look or whether they can be rotated).

In a structured program, we would write a function to draw a shape, containing logic like "if the shape is a circle, do ABC; if it’s a rectangle, do XYZ" and so on.

But in an Object Oriented program, we would simply tell the shape to draw itself, and the shape would know, based on its own type, what to do: we write a specialized drawing function when we define each shape, and when we send a "draw" message to any shape, it automatically calls the one for the correct shape type. Polymorphism eliminates the need for us to check what kind of shape it is: we just have to know that shapes can draw themselves, and let the shape worry about how it actually happens.

Encapsulation

Encapsulation is the phenomenon of hiding internal details of an object. Encapsulation gives an object the ability to hide some of its data and methods and expose others which are required, by virtue of which these data and methods are well protected and not randomly accessed by other code.

For example, all shapes have a location and a size, but the best representation might be different. A circle only needs three numbers (center X, center Y, and radius) but a rectangle needs four (top, bottom, left, right).

Structured programming encourages code everywhere to deal directly with the innards of data structures, so most likely we need to use the same representation for all shapes in order to avoid checking the type every time we want to measure a shape, even though that representation is wasteful for circles.

Object oriented programming addresses that problem two ways: first, encapsulation says that the internal representation of a shape is off-limits to anyone else, so if you want to know how big a shape is, you have to call its getSize() method instead of reading its size directly out of memory. Second, polymorphism allows different shapes to implement their getSize() methods differently, allowing circles to use a more efficient version while presenting the same interface to the outside world.

Inheritance

Inheritance is the mechanism by which the behaviour of a class can be reused in the definition of new classes. Subclasses of a class inherit the operations of their parent class and may add new operations and new instance variables.

This makes it easy to extend existing structures to produce new structures with slightly different behavior. For example, a filled circle is mostly the same as a regular circle, but it draws itself differently and also has a fill color.

In a structured program, we handle filled circles by adding a fill color to allshapes and a flag that indicates whether the shape is filled or not, and the fill color would simply go unused (wasting memory) in unfilled shapes.

In an object-oriented program, we can make FilledCircle a subclass of Circle, inheriting all the existing circle behavior, and then replace the draw() method and add a place to store the fill color. Then if we changed something about Circle later, the change would automatically propagate to FilledCircle, while changes we made to FilledCircle would not affect any other shapes.

What is a better choice/Scalability/Design vs Language

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design. For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the GTK windowing library. On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

Structured programming is generally preferred when we need to write small programs where as Object Oriented Programming is preferred when we need to write huge software and thus it is scalable.