CSC/ECE 517 Fall 2011/ch1 1e sa: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
(→‎History and transition: Added convenient links and remarks.)
m (→‎History and transition: Added another convenient link)
Line 35: Line 35:


===History and transition===
===History and transition===
Early forms of object oriented programming languages were created in the early 1960s with the creation of [http://en.wikipedia.org/wiki/Lisp_(programming_language) LISP] and an early form of ALGOL, with [http://en.wikipedia.org/wiki/Simula Simula 67] signaling the actual beginning of the object-oriented "revolution." The development of object-oriented languages progressed through other languages like [http://en.wikipedia.org/wiki/Simula Smalltalk] and the archetypal C++ to arrive at many of the object oriented languages we have today.<ref name="oopref"/> As processing capability has matured, so too have the capabilities of programming languages. More and more though, [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamic programming languages] like [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] are being treated as "true" object-oriented languages because of their rapid prototpying ability and strong object model.
Early forms of object oriented programming languages were created in the early 1960s with the creation of [http://en.wikipedia.org/wiki/Lisp_(programming_language) LISP] and an early form of ALGOL, with [http://en.wikipedia.org/wiki/Simula Simula 67] signaling the actual beginning of the object-oriented "revolution." The development of object-oriented languages progressed through other languages like [http://en.wikipedia.org/wiki/Simula Smalltalk] and the archetypal C++ to arrive at many of the object oriented languages we have today.<ref name="oopref"/> As processing capability has matured, so too have the capabilities of programming languages. More and more though, [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamic programming languages] like [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] are being treated as "true" object-oriented languages because of their rapid prototpying ability and strong [http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design object model].


===Programming languages===
===Programming languages===

Revision as of 02:56, 15 September 2011

"Block vs Object-Oriented Programming Languages"

In computer science, computer programming languages exhibit variance in syntax and structure in order to effectively solve problems. Two of these variances can be seen between block structure and object-oriented structure. A programming language with block structure allows the programmer to group lines of code for convenient use throughout the rest of the program. Object-oriented structure meanwhile goes further to allow the programmer to associate data with its actions in a hierarchical manner. Object-oriented structure has many advantages which generally make it more effective and durable than block-structured languages, but object-oriented languages also benefit from the core ideas present in block structure programming.

Block structure

Definition

Block-structured programming languages are task-centric, high-level languages. Operations on data sets are emphasized in an attempt to logically organize program operation. The design and implementation involves breaking down the problem into discrete blocks or units which can be nested to any depth or not at all. Each block generally consists of a set of delimiters such as braces or keywords that separate them from other blocks. Each of these blocks contains a set of (optional) declarations and logic to solve a particular problem. Declarations inside of nested blocks introduces the concept of variable scope, which frees the programmer from having to worry about name collisions and other variable maintenance tasks.<ref>Block (programming) at Wikipedia</ref> A code example of a block structured program is provided later in the article.

Overall, block-structured languages can be summarized as having the following features:

  • Modular - Lines of code/functionality are grouped together
  • Scoped - Variables are limited to the group of code they are declared in
  • Top down - Modules are created as necessary to meet the program's requirements
  • Simple - It is generally simpler to "cobble together" modules of code that accomplish a simple, well-defined task.

History

Block-structured languages were first conceived in the 1950s with the advent of ALGOL, one of the first imperative programming languages. An evolution of block structuring was created as the "GOTO" logic of programs became more and more difficult to understand and maintain. In 1968, famed computer scientist Edsger Dijkstra wrote a letter and follow-up article on the ideas and motivation behind "structured programming," where the program exhibits “separation of concerns," single point of entry but multiple points of exit, and ideas of data structures. It was Dijkstra’s and others’ which helped propel this basic idea of block structure programming into the mainstream.<ref>Structured programming at Wikipedia</ref>

Programming languages

Block-structured programming languages dominate the general purpose, imperative programming language arena. Indeed most programming languages in modern use enjoy some of the benefits of block structure with grouping of code and scope of variables. Indeed, ignoring their object-oriented aspects, all of C, C++, C#, Java, PHP and Visual Basic – for example – contain elements of block structure.

Object-oriented structure

Definition

Description

Object-oriented structured languages are data-centric, high-level languages. This is in contrast to block structure languages, which were task-centric. Compared to block-structure languages, logical organization of data and the methods associated with them are emphasized. It is a way of grouping data with executable code (called "objects") that works with that data which exhibits attributes in a hierarchical manner (called "classes" in popular languages). Toward this end and depending on the language, objects can be interrelated and defined so that their relationships can produce code that is well-organized, easy to read, and reusable.<ref name="oopref">Object-oriented programming at Wikipedia</ref>

Principles

Encapsulation

Also referred to as "data hiding," encapsulation shields the programmer from the implementation details of an object. These implementation details would include private variables, special libraries, and data structures that the programmer does not need to know in order to utilize the functionality offered by the object.<ref>Encapsulation (object-oriented programming) at Wikipedia</ref>

Inheritance

Inheritance introduces the idea of objects sharing functionality in data or methods that are common. Subclasses can inherit data structures, functions, and attributes of their superclasses in order to create an object or class hierarchy that is effective in organizing data and methods in a logical manner.<ref>Inheritance (computer science) at Wikipedia</ref>

Polymorphism

Polymorphism describes the idea of interfaces, where one data type can be defined that allows other dissimilar types to implement a common set of methods and fields. This allows a high level of abstraction that allows programmers to write easily maintainable code.<ref>Polymorphism in object-oriented programming at Wikipedia</ref>

History and transition

Early forms of object oriented programming languages were created in the early 1960s with the creation of LISP and an early form of ALGOL, with Simula 67 signaling the actual beginning of the object-oriented "revolution." The development of object-oriented languages progressed through other languages like Smalltalk and the archetypal C++ to arrive at many of the object oriented languages we have today.<ref name="oopref"/> As processing capability has matured, so too have the capabilities of programming languages. More and more though, dynamic programming languages like Ruby are being treated as "true" object-oriented languages because of their rapid prototpying ability and strong object model.

Programming languages

A complete list of object oriented languages is outside the scope of this document, but some major examples are Boo, C++, C#, COBOL, F#, Fortran 2003, Java, MATLAB, Objective-C, PHP5, Python, Ruby, and Visual Basic.<ref>List of object-oriented programming languages at Wikipedia</ref>

Structure comparison

Advantages and disadvantages

Block-structured languages

Advantages
  • Simplicity
  • Reduced coding and turnover time
  • Dynamic lifetime of variables provide efficient usage of memory (since allocation and deletion occur at the entrance and exit of each block)
Disadvantages
  • Commercial projects are difficult to manage due to very large code base sizes
  • Reduced code reusability
  • Security concerns, espcially in the realm of arrays and accessing elements that are out of bounds

Object-Oriented languages

Advantages
  • The software objects model real world objects so program composition is well defined and structured
  • each object's definition and internal implementation is decoupled from other objects, making the system design inherently modular
  • Adding new features becomes easier because of inheritance, allowing the new class to contain the new feature in addition to all old features from the inherited class
  • Debugging is easier since each object's internal mechanisms are independent of each other, which helps in isolating errors and fixing them
  • Enhanced code reusability
Disadvantages
  • The complexity of object-oriented design becomes prohibitive when working on small projects
  • Object-oriented programming paradigm is preferable for dynamic environments rather than simple environments
  • Reduced time efficiency compared to block-structured languages

Summary of important differences

Difference Block Structured Languages Object-Oriented Languages
Problem approach Top-down approach is followed Bottom-up approach is followed
Problem focus Focus is on the algorithm to solve the problem Focus is on getting the object design right
View of data and functions Views data and functions as separate entities Views data and functions as single entity
Cost of maintenance Maintenance is costly Maintenance is relatively cheaper
Software reuse Software reuse is not possible Software reuse is possible
Abstraction Function abstraction is used Data abstraction is used

Effectiveness and durability of object oriented languages over block structured languages

Although block structured languages were simpler and faster for smaller projects, when it comes to large commercial undertaking the manpower and tools required to maintain the code base is very prohibitive. It was very difficult to fix issues, add new features, and at the same time to make sure that the integrity of the code base is intact. Many projects were perpetually stagnant at 90% completion with issues coming up at the eleventh hour. All these problems led to the hastening of the move to object-oriented languages which showed it had the solutions to all the problems that block structured languages could not solve. The following four points are the most important reasons why object-oriented languages were more effective and durable that block structured languages:

  • Maintenance - In block structured languages, especially in large projects, system maintenance became a challenge. Object oriented languages could counter this by providing clear demarcation between the objects and making it easier to work on individual aspects of the system without disturbing the other components.
  • Data hiding - In block structured language system the data usually has global scope. Hence it is very difficult to monitor or supervise data access. This was solved by object-oriented languages by providing data encapsulation. The data and the corresponding attributes are put into a nice little package that was much easier to control and monitor.
  • Code reuse - Object oriented languages are proponents of code reuse. Hence the code size could be reduced sufficiently enough when it comes to large projects to warrant a shift from block structured to object oriented languages.
  • Feature additions - Object oriented languages provide a very cost effective and safe way to add new features to the existing system without causing the whole system to collapse. This feature is very important for large scale software vendors who provide various customizations.

Applicability between paradigms

Object-oriented languages have solved many problems that block structured languages introduced. But all is not lost with block structured languages. They boast some very important features that are needed in any programming language. The simplicity and readability of code in block structured languages are enviable features indeed. Because of this very simplicity we find that block structured languages are very efficient in terms of speed and performance. Such a language would also provide the flexibility in moving legacy block structured systems to the object oriented paradigm seamlessly. A language that can capture both sides of the argument would be a formidable entry into the growing list of programming languages. This explains why we see C++ emerging as one of the most popular object oriented languages. It has both the block structured features of C and the object-oriented concepts built into it, thereby making it a very versatile and efficient programming language.

C/C++ Code Example

Below is a code example highlighting key differences between a block structured program and an object oriented program all in one source file.

// For block structure, leave the below line commented to compile in C
// For object oriented structure, uncomment the line to compile in C++
//#define USING_CPP

#ifndef USING_CPP

// C standard header files
#include <stdio.h>
#include <stdlib.h>

// Define the messages of each persona
#define KING_MESSAGE   "Read my lips: No new taxes"
#define JESTER_MESSAGE "My wife and I were happy for 20 years. Then we met."
#define PEON_MESSAGE   "The king himself created his own worst enemy, just as tyrants everywhere do!"

// Define the function prototypes for delivering the different messages
char *getKingMessage();
char *getJesterMessage();
char *getPeonMessage();

// Main program entry point
int main()
{
	// Go through and make each function call for...
	// The King
	printf("And now a message from the king: %s\n", getKingMessage());
	printf("The King has spoken!\n\n");

	// The Court Jester
	printf("And now a message from the court jester: %s\n", getJesterMessage());
	printf("Wocka wocka wocka!\n\n");

	// A Peon
	printf("And now a message from a peon: %s\n", getPeonMessage());
	printf("... but don't mind me!\n\n");
	
	// Wait for user input before exiting
	system("pause");

	return 0;
}

// Returns a string containing the text to be spoken by the king
char *getKingMessage()
{
	return KING_MESSAGE;
}

// Returns a string containing the text to be spoken by the court jester
char *getJesterMessage()
{
	return JESTER_MESSAGE;
}

// Returns a string containing the text to be spoken by all peons
char *getPeonMessage()
{
	return PEON_MESSAGE;
}
#endif

#ifdef USING_CPP

// C++ standard headers
#include <cstdio>
#include <cstdlib>

// Define what each persona should say
#define KING_MESSAGE   "Read my lips: No new taxes"
#define JESTER_MESSAGE "My wife and I were happy for 20 years. Then we met."
#define PEON_MESSAGE   "The king himself created his own worst enemy, just as tyrants everywhere do!"

// Keep all classes clearly separated from other sections of code
namespace Monarchy
{
	// Define a basic class where a person has a label and something they want to say
	class Person
	{
	private:
		char *szMessage;
		char *szLabel;

	public:
		// Allow a person to deliver their message
		void DeliverMessage()
		{
			printf("A now a message from %s: %s\n", this->szLabel, this->szMessage);
		}

		// A person needs to be initialized with a label and a message
		Person(char*label, char *msg)
		{
			this->szLabel = label;
			this->szMessage = msg;
		}
	};

	// The King is a person (and thus inherits from it)
	class King : public Person
	{
	public:
		// The king has the same label, but his message might change according to the political winds
		King(char *msg) : Person("the king", msg)
		{
		}

		// Here, the function is being overridden...
		void DeliverMessage()
		{
			// .. but the base class's DeliverMessage is still being called, in addition to the tag line
			Person::DeliverMessage();
			printf("The King has spoken!\n\n");
		}
	};

	// A peon is a person (and thus inherits from it)
	class Peon : public Person
	{
	public:
		// A peon has the same label but his message might change according to his or her attitude toward the king
		Peon(char *msg) : Person("a peon", msg)
		{
		}

		// Like above, deliver the message, but always provide a common tag line
		void DeliverMessage()
		{
			Person::DeliverMessage();
			printf("... but don't mind me!\n\n");
		}
	};

	// A jester is a person (and thus inherits from it)
	class Jester : public Person
	{
	public:
		// A peon has the same label but his message might change if the king is sick of his jokes
		Jester(char *msg) : Person("the court jester", msg)
		{
		}

		// Might as well call him Fozzie ;)
		void DeliverMessage()
		{
			Person::DeliverMessage();
			printf("Wocka wocka wocka!\n\n");
		}
	};
}

// Main program entry point
int main()
{
	// Initialize some monarchy objects
	Monarchy::King TheKing(KING_MESSAGE);
	Monarchy::Jester Borat(JESTER_MESSAGE);
	Monarchy::Peon Bruno(PEON_MESSAGE);

	// Let them deliver their messages
	TheKing.DeliverMessage();
	Borat.DeliverMessage();
	Bruno.DeliverMessage();

	// Wait for user input
	system("pause");

	return 0;
}
#endif

See also

References

<references/>

Further reading

  • Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. Head First Design Patterns. Sebastopol, CA: O'Reilly, 2004. Print.
  • Liberty, Jesse. Sams Teach Yourself C++ in 24 Hours. Indianapolis, IN: Sams, 2002. Print.
  • Microsoft Visual C++ Language Reference. Redmond, WA: Microsoft, 1997. Print.
  • Weiss, Mark Allen. Data Structures & Algorithm Analysis in Java. Reading, MA: Addison-Wesley, 1999. Print.

External links