CHAPTER 1 ■ OVERVIEW OF OBJECT-ORIENTED PROGRAMMING
2
OOP concepts started surfacing in the mid-1960s with a programming language called Simula and
further evolved in the 70s with advent of Smalltalk. Although software developers did not
overwhelmingly embrace these early advances in OOP languages, object-oriented methodologies
continued to evolve. In the mid-80s there was a resurgence of interest in object-oriented methodologies.
Specifically, OOP languages such as C++ and Eifle became popular with mainstream computer
programmers. OOP continued to grow in popularity in the 90s, most notably with the advent of Java and
the huge following it attracted. And in 2002, in conjunction with the release of the .NET Framework,
Microsoft introduced a new OOP language, C# (pronounced C-sharp) and revamped Visual Basic so that
it is truly an OOP language.
Why Use OOP?
Why has OOP developed into such a widely used paradigm for solving business problems today? During
the 70s and 80s, procedural-oriented programming languages such as C, Pascal, and Fortran were widely
used to develop business-oriented software systems. Procedural languages organize the program in a
linear fashion—they run from top to bottom. In other words, the program is a series of steps that run one
after another. This type of programming worked fine for small programs that consisted of a few hundred
code lines, but as programs became larger they became hard to manage and debug.
In an attempt to manage the ever-increasing size of the programs, structured programming was
introduced to break down the code into manageable segments called functions or procedures. This was
an improvement, but as programs performed more complex business functionality and interacted with
other systems, the following shortcomings of structural programming methodology began to surface:
• Programs became harder to maintain.
• Existing functionality was hard to alter without adversely affecting all of the
system’s functionality.
• New programs were essentially built from scratch. Consequently, there was little
return on the investment of previous efforts.
• Programming was not conducive to team development. Programmers had to
know every aspect of how a program worked and could not isolate their efforts on
one aspect of a system.
• It was hard to translate business models into programming models.
• It worked well in isolation but did not integrate well with other systems.
In addition to these shortcomings, some evolutions of computing systems caused further strain on
the structural program approach, such as:
• Nonprogrammers demanded and were given direct access to programs through
the incorporation of graphical user interfaces and their desktop computers.
• Users demanded a more-intuitive, less-structured approach to interacting with
programs.
• Computer systems evolved into a distributed model where the business logic, user
interface, and backend database were loosely coupled and accessed over the
Internet and intranets.
我的内容管理
展开
