CSC/ECE 517 Fall 2012/ch2a 2w15 rr: Difference between revisions
| Line 8: | Line 8: | ||
==Object Oriented Design Perspectives== | ==Object Oriented Design Perspectives== | ||
===Language-centric perspective=== | ===Language-centric perspective=== | ||
The focus of the language-centric perspective is classes and objects as building blocks for developing software. The emphasis is on the internal structure which are the fields and methods. Thus it is inherently a compile-time or static view which means that the definition speaks in terms of what it | The focus of the language-centric perspective is classes and objects as building blocks for developing software. The emphasis is on the internal structure which are the fields and methods. Thus it is inherently a compile-time or static view which means that the definition speaks in terms of what it looks like in the following code: | ||
<pre> | <pre> | ||
public class foo | public class foo | ||
| Line 22: | Line 22: | ||
</pre> | </pre> | ||
The implicit aspect of this view is that an object is an entity in its own | The implicit aspect of this view is that, an object is an entity in its own right and the definition is closed. Any object can be understood in isolation where the fields and methods and you are done. | ||
The advantage of this perspective is of course that it is very concrete, closely related to | The advantage of this perspective is of course that it is very concrete, closely related to | ||
the programming language level, and therefore relatively easy to understand at an introductory level. | the programming language level, and therefore relatively easy to understand at an introductory level. | ||
Revision as of 22:22, 22 October 2012
Introduction
Object-oriented design is a programming model that began in the late 60's as software programs became more complex. The idea behind the approach was to build software systems by modeling them based on the real-world objects that they were trying to represent. For example, banking systems would contain customer objects, account objects, etc. Today, object-oriented design has been widely adopted <ref> Introduction to Object Oriented Design</ref>. When done properly, this approach leads to simple, robust, flexible and modular software. When something goes wrong, the results could be bad. Object oriented design can be seen from different perspectives. In the language-centric perspective, objects are containers of data and methods. The model-centric perspective views the objects as model elements reflecting the real world objects and Responsibility-centric perspective views objects as interacting elements each playing a role in object community. Each of these perspectives are outlined in the following sections.
Background
The history of object oriented design has many branches, and many people have contributed to this domain. The 1960s and 1970s saw the emergence of object oriented programming languages, such as Simula and Smalltalk, with key contributors such as Kristen Nygaard and Alan Kay, the visionary computer scientist who founded Smalltalk.<ref>History of Object Oriented Design</ref> But object oriented design was informal through that period, and it was only form 1982 that it became popular. Contributors in this domain include Grady Booch, Kent Beck, Peter Coad, Don Firesmith, Ivar Jacobson (a UML founder), Steve Mellor, Bertrand Meyer, Jim Rumbaugh (a UML founder) and Rebecca Wirfs-Brock among others. Each of these perspectives are outlined in the following sections.
Object Oriented Design Perspectives
Language-centric perspective
The focus of the language-centric perspective is classes and objects as building blocks for developing software. The emphasis is on the internal structure which are the fields and methods. Thus it is inherently a compile-time or static view which means that the definition speaks in terms of what it looks like in the following code:
public class foo
{
private int x;
public static double y;
public int double (int x)
{
return (3*x);
}
}
The implicit aspect of this view is that, an object is an entity in its own right and the definition is closed. Any object can be understood in isolation where the fields and methods and you are done. The advantage of this perspective is of course that it is very concrete, closely related to the programming language level, and therefore relatively easy to understand at an introductory level.
The disadvantage is, however, that it remains relatively silent about how to structure the collaboration and interplay between objects, the dynamics, and this is typically where the hard challenges of design lie. Thus the perspective offers little guidance in the process of designing any realistic system.
Model-centric perspective
Responsibility-centric perspective
References
<references />