JustAnswer



Object-oriented programming in detail

Object-oriented programming (OOP) is a programming paradigm that uses "objects" – data structures consisting of datafields and methods – and their interactions to design applications and computer programs. Programming techniques may include features such as information hiding, data abstraction, encapsulation, modularity, polymorphism, and inheritance. It was not commonly used in mainstream software application development until the early 1990s. Many modern programming languages now support OOP.

Overview

Object-oriented programming has roots that can be traced to the 1960s. As hardware and software became increasingly complex, quality was often compromised. Researchers studied ways to maintain software quality and developed object-oriented programming in part to address common problems by strongly emphasizing discrete, reusable units of programming logic. The methodology focuses on data rather than processes, with programs composed of self-sufficient modules (objects) each containing all the information needed to manipulate its own data structure. This is in contrast to the existing modular programming which had been dominant for many years that focused on the function of a module, rather than specifically the data, but equally provided for code reuse, and self-sufficient reusable units of programming logic, enabling collaboration through the use of linked modules (subroutines). This more conventional approach, which still persists, tends to consider data and behavior separately.

An object-oriented program may thus be viewed as a collection of cooperating objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects and can be viewed as an independent 'machine' with a distinct role or responsibility. The actions (or "operators") on these objects are closely associated with the object. For example, the data structures tend to carry their own operators around with them (or at least "inherit" them from a similar object or class).

The Simula programming language was the first to introduce the concepts underlying object-oriented programming (objects, classes, subclasses, virtual methods, coroutines, and discrete event simulation) as a superset of Algol. Simula also used automatic garbage collection which had been invented earlier for the functional programming language Lisp. Simula was used for physical modeling, such as models to study and improve the movement of ships and their content through cargo ports. Smalltalk was the first programming language to be called "object-oriented".

History

The concept of objects and instances in computing had its first major breakthrough with the PDP-1 system at MIT which was probably the earliest example of capability based architecture. Another early example was Sketchpad made by Ivan Sutherland in 1963; however, this was an application and not a programming paradigm. Objects as programming entities were introduced in the 1960s in Simula 67, a programming language designed for making simulations, created by Ole-Johan Dahl and Kristen Nygaard of the Norwegian Computing Center in Oslo. (They were working on ship simulations, and were confounded by the combinatorial explosion of how the different attributes from different ships could affect one another. The idea occurred to group the different types of ships into different classes of objects, each class of objects being responsible for defining its own data and behavior.) Such an approach was a simple extrapolation of concepts earlier used in analog programming. On analog computers, mapping from real-world phenomena/objects to analog phenomena/objects (and conversely), was (and is) called 'simulation'. Simula not only introduced the notion of classes, but also of instances of classes, which is probably the first explicit use of those notions. The ideas of Simula 67 influenced many later languages, especially Smalltalk and derivatives of Lisp and Pascal.

The Smalltalk language, which was developed at Xerox PARC (by Alan Kay and others) in the 1970s, introduced the term object-oriented programming to represent the pervasive use of objects and messages as the basis for computation. Smalltalk creators were influenced by the ideas introduced in Simula 67, but Smalltalk was designed to be a fully dynamic system in which classes could be created and modified dynamically rather than statically as in Simula 67 Smalltalk and with it OOP were introduced to a wider audience by the August 1981 issue of Byte magazine.

In the 1970s, Kay's Smalltalk work had influenced the Lisp community to incorporate object-based techniques which were introduced to developers via the Lisp machine. Experimentation with various extensions to Lisp (like LOOPS and Flavors introducing multiple inheritance and mixins), eventually led to the Common Lisp Object System (CLOS, a part of the first standardized object-oriented programming language, ANSI Common Lisp), which integrates functional programming and object-oriented programming and allows extension via a Meta-object protocol. In the 1980s, there were a few attempts to design processor architectures which included hardware support for objects in memory but these were not successful. Examples include the Intel iAPX 432 and the Linn Smart Rekursiv.

Object-oriented programming developed as the dominant programming methodology during the mid-1990s, largely due to the influence of C++. Its dominance was further enhanced by the rising popularity of graphical user interfaces, for which object-oriented programming seems to be well-suited. An example of a closely related dynamic GUI library and OOP language can be found in the Cocoa frameworks on Mac OS X, written in Objective-C, an object-oriented, dynamic messaging extension to C based on Smalltalk. OOP toolkits also enhanced the popularity of event-driven programming (although this concept is not limited to OOP). Some feel that association with GUIs (real or perceived) was what propelled OOP into the programming mainstream.

At ETH Zürich, Niklaus Wirth and his colleagues had also been investigating such topics as data abstraction and modular programming. Modula-2 included both, and their succeeding design, Oberon, included a distinctive approach to object orientation, classes, and such. The approach is unlike Smalltalk, and very unlike C++.

Object-oriented features have been added to many existing languages during that time, including Ada, BASIC, Fortran, Pascal, and others. Adding these features to languages that were not initially designed for them often led to problems with compatibility and maintainability of code.

More recently, a number of languages have emerged that are primarily object-oriented yet compatible with procedural methodology, such as Python and Ruby. Probably the most commercially important recent object-oriented languages are Visual Basic .NET () and C#, both designed for Microsoft's .NET platform, and Java, developed by Sun Microsystems. and C# both support cross-language inheritance, allowing classes defined in one language to subclass classes defined in the other language.

Just as procedural programming led to refinements of techniques such as structured programming, modern object-oriented software design methods include refinements such as the use of design patterns, design by contract, and modeling languages (such as UML).

The term OOPS, which refers to an object-oriented programming system, was common in early development of object-oriented programming.

Fundamental concepts and features

A survey by Deborah J. Armstrong of nearly 40 years of computing literature identified a number of "quarks", or fundamental concepts, found in the strong majority of definitions of OOP. They are the following:

Class 

Defines the abstract characteristics of a thing (object), including the thing's characteristics (its attributes, fields or properties) and the thing's behaviors (the things it can do, or methods, operations or features). One might say that a class is a blueprint or factory that describes the nature of something. For example, the class Dog would consist of traits shared by all dogs, such as breed and fur color (characteristics), and the ability to bark and sit (behaviors). Classes provide modularity and structure in an object-oriented computer program. A class should typically be recognizable to a non-programmer familiar with the problem domain, meaning that the characteristics of the class should make sense in context. Also, the code for a class should be relatively self-contained (generally using encapsulation). Collectively, the properties and methods defined by a class are called members.

Object 

A pattern (exemplar) of a class. The class of Dog defines all possible dogs by listing the characteristics and behaviors they can have; the object Lassie is one particular dog, with particular versions of the characteristics. A Dog has fur; Lassie has brown-and-white fur.

Instance 

One can have an instance of a class or a particular object. The instance is the actual object created at runtime. In programmer jargon, the Lassie object is an instance of the Dog class. The set of values of the attributes of a particular object is called its state. The object consists of state and the behaviour that's defined in the object's class.

Method 

An object's abilities. In language, methods (sometimes referred to as "functions") are verbs. Lassie, being a Dog, has the ability to bark. So bark() is one of Lassie's methods. She may have other methods as well, for example sit() or eat() or walk() or save_timmy(). Within the program, using a method usually affects only one particular object; all Dogs can bark, but you need only one particular dog to do the barking.

Message passing 

"The process by which an object sends data to another object or asks the other object to invoke a method." Also known to some programming languages as interfacing. For example, the object called Breeder may tell the Lassie object to sit by passing a "sit" message which invokes Lassie's "sit" method. The syntax varies between languages, for example: [Lassie sit] in Objective-C. In Java, code-level message passing corresponds to "method calling". Some dynamic languages use double-dispatch or multi-dispatch to find and pass messages.

Inheritance 

"Subclasses" are more specialized versions of a class, which inherit attributes and behaviors from their parent classes, and can introduce their own.

For example, the class Dog might have sub-classes called Collie, Chihuahua, and GoldenRetriever. In this case, Lassie would be an instance of the Collie subclass. Suppose the Dog class defines a method called bark() and a property called furColor. Each of its sub-classes (Collie, Chihuahua, and GoldenRetriever) will inherit these members, meaning that the programmer only needs to write the code for them once.

Each subclass can alter its inherited traits. For example, the Collie class might specify that the default furColor for a collie is brown-and-white. The Chihuahua subclass might specify that the bark() method produces a high pitch by default. Subclasses can also add new members. The Chihuahua subclass could add a method called tremble(). So an individual chihuahua instance would use a high-pitched bark() from the Chihuahua subclass, which in turn inherited the usual bark() from Dog. The chihuahua object would also have the tremble() method, but Lassie would not, because she is a Collie, not a Chihuahua. In fact, inheritance is an "a... is a" relationship between classes, while instantiation is an "is a" relationship between an object and a class: a Collie is a Dog ("a... is a"), but Lassie is a Collie ("is a"). Thus, the object named Lassie has the methods from both classes Collie and Dog.

Multiple inheritance is inheritance from more than one ancestor class, neither of these ancestors being an ancestor of the other. For example, independent classes could define Dogs and Cats, and a Chimera object could be created from these two which inherits all the (multiple) behavior of cats and dogs. This is not always supported, as it can be hard both to implement and to use well.

Abstraction 

Abstraction is simplifying complex reality by modeling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem.

For example, Lassie the Dog may be treated as a Dog much of the time, a Collie when necessary to access Collie-specific attributes or behaviors, and as an Animal (perhaps the parent class of Dog) when counting Timmy's pets.

Abstraction is also achieved through Composition. For example, a class Car would be made up of an Engine, Gearbox, Steering objects, and many more components. To build the Car class, one does not need to know how the different components work internally, but only how to interface with them, i.e., send messages to them, receive messages from them, and perhaps make the different objects composing the class interact with each other.

Encapsulation 

Encapsulation conceals the functional details of a class from objects that send messages to it.

For example, the Dog class has a bark() method. The code for the bark() method defines exactly how a bark happens (e.g., by inhale() and then exhale(), at a particular pitch and volume). Timmy, Lassie's friend, however, does not need to know exactly how she barks. Encapsulation is achieved by specifying which classes may use the members of an object. The result is that each object exposes to any class a certain interface — those members accessible to that class. The reason for encapsulation is to prevent clients of an interface from depending on those parts of the implementation that are likely to change in the future, thereby allowing those changes to be made more easily, that is, without changes to clients. For example, an interface can ensure that puppies can only be added to an object of the class Dog by code in that class. Members are often specified as public, protected or private, determining whether they are available to all classes, sub-classes or only the defining class. Some languages go further: Java uses the default access modifier to restrict access also to classes in the same package, C# and reserve some members to classes in the same assembly using keywords internal (C#) or Friend (), and Eiffel and C++ allow one to specify which classes may access any member.

(Subtype) polymorphism 

Polymorphism allows the programmer to treat derived class members just like their parent class' members. More precisely, Polymorphism in object-oriented programming is the ability of objects belonging to different data types to respond to method calls of methods of the same name, each one according to an appropriate type-specific behavior. One method, or an operator such as +, -, or *, can be abstractly applied in many different situations. If a Dog is commanded to speak(), this may elicit a bark(). However, if a Pig is commanded to speak(), this may elicit an oink(). They both inherit speak() from Animal, but their derived class methods override the methods of the parent class; this is Overriding Polymorphism. Overloading Polymorphism is the use of one method signature, or one operator such as "+", to perform several different functions depending on the implementation. The "+" operator, for example, may be used to perform integer addition, float addition, list concatenation, or string concatenation. Any two subclasses of Number, such as Integer and Double, are expected to add together properly in an OOP language. The language must therefore overload the addition operator, "+", to work this way. This helps improve code readability. How this is implemented varies from language to language, but most OOP languages support at least some level of overloading polymorphism. Many OOP languages also support parametric polymorphism, where code is written without mention of any specific type and thus can be used transparently with any number of new types. Pointers are an example of a simple polymorphic routine that can be used with many different types of objects.

Decoupling 

Decoupling allows for the separation of object interactions from classes and inheritance into distinct layers of abstraction. A common use of decoupling is to polymorphically decouple the encapsulation, which is the practice of using reusable code to prevent discrete code modules from interacting with each other. However, in practice decoupling often involves trade-offs with regard to which patterns of change to favor. The science of measuring these trade-offs in respect to actual change in an objective way is still in its infancy.

Not all of the above concepts are to be found in all object-oriented programming languages, and so object-oriented programming that uses classes is called sometimes class-based programming. In particular, prototype-based programming does not typically use classes. As a result, a significantly different yet analogous terminology is used to define the concepts of object and instance.

Main features

The attempt to distill OOP to a minimal set of features is considered futile by programming language researcher Benjamin C. Pierce. Nevertheless, he identifies the following as fundamental features that are found in most object-oriented languages and that, in concert, support the OOP programming style:

• Dynamic dispatch -- when a method is invoked on an object, the object itself determines what code gets executed by looking up the method at run time in a table associated with the object. This feature distinguishes an object from an abstract data type (or module), which has a fixed (static) implementation of the operations for all instances

• Encapsulation (or multi-methods, in which case the state is kept separate)

• Subtype polymorphism

• Class inheritance (or delegation)

• Open recursion -- a special variable (syntactically it may be a keyword), usually called this or self, that allows a method body to invoke another method body of the same object. This variable is late-bound; it allows a method defined in one class to invoke another method that is defined later, in some subclass thereof.

Similarly, in hist 2003 book, Concepts in programming languages, John C. Mitchell identifies four main features: dynamic dispatch, abstraction, subtype polymorphism, and inheritance Michael Lee Scott in Programming Language Pragmatics considers only encapsulation, inheritance and dynamic dispatch.

OOP languages

Simula (1967) is generally accepted as the first language to have the primary features of an object-oriented language. It was created for making simulation programs, in which what came to be called objects were the most important information representation. Smalltalk (1972 to 1980) is arguably the canonical example, and the one with which much of the theory of object-oriented programming was developed.

• Languages called "pure" OO languages, because everything in them is treated consistently as an object, from primitives such as characters and punctuation, all the way up to whole classes, prototypes, blocks, modules, etc. They were designed specifically to facilitate, even enforce, OO methods. Examples: Smalltalk, Eiffel, Ruby, JADE

• Languages designed mainly for OO programming, but with some procedural elements. Examples: C++, Java, Python.

• Languages that are historically procedural languages, but have been extended with some OO features. Examples: Fortran 2003, Perl, COBOL 2002.

• Languages with most of the features of objects (classes, methods, inheritance, reusability), but in a distinctly original form. Examples: Oberon (Oberon-1 or Oberon-2).

• Languages with abstract data type support, but not all features of object-orientation, sometimes called object-based languages. Examples: Modula-2 (with excellent encapsulation and information hiding), Pliant, CLU.

How OOP could support a company's organizational goals? How would this happen?

Company’s organizational goals are very vast and OOP is the only concept which can support them.

Protection

Protection is the feature of protecting elements from improper, usually careless, actions or associations. It often takes the form of rules or tags on programming elements which say, "You are not allowed to do such and such," or "You must do such and such or I will not compile you."

The earlier in the process a problem is detected, the better the "protection" is considered:

1. At compile or syntax checking (lint) time.

2. At load time (such as loading an EXE file into memory or a script into an interpreter).

3. At execution (run) time.

4. Long after the mess was made.

Most languages have at least some amount of protection, otherwise mistakes would usually result in memory space violations or program aborts beyond the interpreter or language handlers.

Protection often adds limits to scope, context, ranges, and usage. Protection often, but not always, takes the form of clauses or modifier keywords. For example, in Java the "abstract" keyword disallows a class from having runnable code. Similarly, the Java "final" keyword prevents one from formally extending (inheriting from) any class marked as "final."

Array bounds checking is also a form of protection. Without it, a program may end up rewriting itself when the index goes out of bounds.

Proximity

Proximity is the goal of having relating items placed physically together in our software. This simplifies software maintenance and inspection by reducing the jumping around needed to make changes or inspect code. Traditional (procedural) programming tended to group like items by behavior. However, OOP allows one to also group by subclass. (See our discussion about Control Table theory for a deeper discussion of these two groupings.)

OOP proponents often claim that the subclass grouping (SOMPI) is superior to the procedural grouping (SIMPO). However, this has not been shown to be the case a significant majority of the time. Grouping by operation (SIMPO) has it's own benefits at times.

This tug-of-war between the two arrangements has prompted us to combine the two arrangements so that we can have both groupings at the same time. How can this be done? By adding a dimension. OOP code and procedural code are generally one-dimensional in concept. However, Control Tables are two-dimensional in concept. Thus, one is not forced to pick one grouping at the expense of another.

Part of this gets into the issue of code indexing so that related code can be found. If we look at the world of document indexing and RDBMS, queries can be on multiple criteria, and with complex expressions. OOP and its single-class "encapsulation" is limited. It is like being forced to have only one field/parameter for all code queries. In other words, it does not scale. It is yet another example of IS-A thinking. To be fair, procedural design has also been traditionally limited to one code indexing aspect (routines). One possible solution is a variation on Control Tables, where RDBMS can be used to index code segments on multiple criteria. A glimpse can be seen in the Multiple Dispatch Pattern example. It is an area that can use more research even if you reject using RDBMS technology.

The bottom line is that OOP has no clear victory in the proximity category. It allows a proximity alternative that procedural programming does not do very well, but it still forces an awkward tradeoff on the software designer.

Internal Reuse

In this write-up we are going to distinguish between internal reuse and external reuse. Internal reuse is code reuse within the same or closely related project. Often "frameworks" are built to support a family of applications which share commonalties. For example, a company may produce a family of graphics applications which may share a core graphic rendering engine.

It appears that the goal of internal reuse and external reuse often conflict with each other because they require different granularity (chunk sizes) in the parts intended for reuse.

OOP does fairly well at this type of reuse, especially if RDBMS are not involved. However, the need for "application families" is not that common in custom, internal business software. Most companies have only one accounting system, one inventory system, one billing system, etc. Except for some aspects of the user interface perhaps, these different sub-systems share very little potential core logic.

Note that inheritance is often cited as a reuse tool because subclasses do not have to re-implement inherited methods and attributes. However, I have found that procedural programming and other paradigms can provide very similar "default" behavior when needed. (It is usually a very different structure, but is not more overall code.) This approach also has the advantage of that the features don't have to fit into a lockstep pattern usually needed for subtyping. Thus, inheritance's contribution to reuse is way over-hyped.

External Reuse

External reuse is the ability to take parts of one application or library and transplant them into a completely different one, usually created at a different time or organization.

It is my experience that taking advantage of this type of reuse generally requires either very small components, or components with relatively simple, well-defined interfaces.

If the components have complex interfaces or require interfacing with complex structures (tables, classes, etc.), then it is often just as easy to rebuild the components from scratch anyhow. This is because the systems often model the same type of things in very different ways.

Even though two similar companies both have payroll operations, their data modeling will probably be very different. It is similar to the way that different vocal languages use very different structures to say the same thing (especially when you compare languages from different continents). Such things just do not have a one-to-one correspondence and require complex and risky re-mappings. Anyone who has ever been involved in total system conversions will realize this. The combinations and philosophies make for zillions of different ways to do and model the same general operations.

The protocol coupling analogy illustrated the "tying" nature of many OO designs. This makes the pieces more conceptually dependent on each other, and thus the whole OO application, or at least very large chunks of it, must be transplanted together.

Overall, promoted usages of OOP, like protocol coupling, often work against external reuse.

Self Documentation

OOP often provides structure and element modifiers that formally state limitations of who or what can read or modify what. Keywords like "private", "protected", "final", etc. often appear in OOP languages.

It is often said that these have two purposes. 1) formally protect, and 2) Document that something should be protected.

Although, such features are "nice", their use does not significantly improve the overall program in my opinion. First of all, since they provide very little immediate benefit, many programmers will avoid using them. Second, they can be eliminated if the follow-on programmer does not want to "obey" them. Third, using regular comments instead of formal keywords keeps the language simpler.

Fourth, this type of documentation only solves half of the problem. To be effective, and programmer needs to know:

1. What should be protected

2. Why is should be protected

The OOP keywords generally do not tell WHY something should be protected. This often requires further comments. If further comments are needed anyhow, then including keywords is somewhat redundant. It seems to me that you might as well just supply good comments to begin with rather than try to formalize a spanking system.

Simplicity

This is an attempt to keep the code simple. A common (but imperfect) measurement is the number of "tokens" needed. Tokens will be defined variables, objects, methods, keywords, operators, specifiers, etc.

Whether OOP makes the program simpler, more complicated, or whatnot is highly contested. Some argue that the protective nature of OO philosophy produces more code. For example, one is often encouraged to write "set" and "get" methods instead of simple assignments to attributes:

method getAmount() {

return this.Amount

}

method setAmount(t) {

if valid(t) {

this.Amount = t

else {

exception ...

}

}

I find these cumbersome, especially when there are a lot of fields (attributes). Bloating up the code with these repetitious structures makes useful stuff harder to find and read. Validation is an important operation, but there are many other ways to deal with it besides building Set methods for every single attribute. Data Dictionaries are one approach that I prefer. (Set/Get operations are not needed in all OO languages. See also Double Dipping.)

Repetition Factoring

Repetition factoring is about removing repetition of structure and/or code by moving it into a single or fewer locations. See the "Buzzwords" entry for more on this.

Repetition factoring (RF) is different from the term "factoring" by itself. Factoring has grown to encompass too many concepts to be a useful metric or point of clear discussion.

Although repetition factoring is generally a "good thing," one point to be careful about is factoring stuff that is somewhat likely to grow apart in the future. Just because something is the same/similar today does not mean that it will be the same/similar tomorrow.

Some argue that RF should be done even for stuff that is coincidentally or temporarily similar. They argue that one can always pull them apart if they grow too different. However, altering code simply to reorganize it as opposed to adding new functionality is generally frowned upon in my experience. (Assuming that there is even a budget for such rearranging.)

See also the Boundary issue.

Share-ability

This is the ability to share information with other languages and paradigms. I have argued that OO often makes this harder because of it's tendency to tie data with behavior.

Maintainability

Maintainability is the amount of effort needed to make changes to an existing system. OOT proponents often cite maintainability as a primary benefit of OOT. However, their arguments often make assumptions about the nature of changes that often do not fit the real world very well in my opinion.

The first assumption that we already talked about is hierarchical changes.

The second problematic assumption is that most changes are favorable to the subclass grouping (SOMPI). This just may not be the case.

Code Size

This criteria is similar to simplicity (above). However, there are times when they are not the same. For example, SQL correlated sub-queries are usually smaller than their procedural counterpart. However, many find correlated sub-queries unintuitive and unreducible in the traditional sense.

Regular expressions (parsing codes) are another example of code which can be small, yet complicated to the unpracticed.

Rapid Development

This is the ability to generate an application that fits requirements very fast. There are many many tradeoffs to having something ready fast and having something that will be maintainable and expandable in the longer run.

Most of the claims for RAD in OOP relate to alleged increased reuse, not so much its ability to generate completely new code. Reuse was discussed above.

Change Impact Tracing

This is the about being able to trace or track the impact of changes back to as many impact points as possible. OOP's potentially tight protection may make change impact analysis easier. However, I have not explored this enough to make any definite conclusions. I suspect OO can improve change impact tracing; but at the price of code bloat, such as extra meta classes. (See also Machine-targeted syntax.)

Compiled Unit Separation

Although I generally prefer interpreted languages, having the ability to separate compiled portions for distribution often comes up in discussions. Often it comes down to aspect tradeoff issues again: one paradigm may favor B-aspect separations at the expense of C-aspect separations, for example. See also Challenge #3. (Note that some interpreters can run encrypted p-code to protect the source code from snoopers.)

Further, the granularity of compilation is very language-dependant. I have used procedural languages that could compile at the routine level and not just the module level.

There is no law that says a language cannot be made to compile at the block or even line level. Whether that is practical or needed is another issue.

Sometimes a variation of this metric is called "intrusiveness", meaning having to "touch" existing code units to make changes. The theory is that one may Bump Thy Neighbor in the change editing process and break something. In my opinion, this fear is sometimes exaggerated unless perhaps it is a medical device or astronaut life-support system. Bumping nearby code is not significantly more likely than editing the wrong file/class/routine. Many editors make it just as easy to grab the wrong file as it is to scramble a nearby code block. This kind of error may all be relative to the editing or code management tools being used. Nothing prevents a "block-lock" editor from being built to protect neighbor blocks. You could treat files as blocks and blocks a files (or put them in tables).

Consistency

Consistency is the goal or ability to keep the design consistent from one project to the next, and/or for different developers to produce designs that are consistent. It is generally easier to read and understand code if there is some predictable pattern or organizational philosophy. See Goto Discussion below for more on this.

Advantages/Disadvantages of OOP and what might be its future in supporting a company's organizational goals?

Advantages of OOP

Object-Oriented Programming has the following advantages over conventional approaches:

• OOP provides a clear modular structure for programs which makes it good for defining abstract datatypes where implementation details are hidden and the unit has a clearly defined interface.

• OOP makes it easy to maintain and modify existing code as new objects can be created with small differences to existing ones.

• OOP provides a good framework for code libraries where supplied software components can be easily adapted and modified by the programmer. This is particularly useful for developing graphical user interfaces.

Disadvantages of OOP

There are a number of programming challenges which a developer encounters regularly in object-oriented design. There are also widely accepted solutions to these problems. The best known are the design patterns codified by Gamma et al., but in a broader sense the term "design patterns" can be used to refer to any general, repeatable solution to a commonly occurring problem in software design. Some of these commonly occurring problems have implications and solutions particular to object-oriented development.

Inheritance and behavioral subtyping

See also: Object oriented design

It is intuitive to assume that inheritance creates a semantic "is a" relationship, and thus to infer that objects instantiated from subclasses can always be safely used instead of those instantiated from the superclass. This intuition is unfortunately false in most OOP languages, in particular in all those that allow mutable objects. Subtype polymorphism as enforced by the type checker in OOP languages (with mutable objects) cannot guarantee behavioral subtyping in a any context. Behavioral subtyping is undecidable in general, so it cannot be implemented by a program (compiler). Class or object hierarchies need to be carefully designed considering possible incorrect uses that cannot be detected syntactically. This issue is known as the Liskov substitution principle.

Gang of Four design patterns

Main article: Design Patterns

Design Patterns: Elements of Reusable Object-Oriented Software is an influential book published in 1995 by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, sometimes casually called the "Gang of Four". Along with exploring the capabilities and pitfalls of object-oriented programming, it describes 23 common programming problems and patterns for solving them. As of April 2007, the book was in its 36th printing. Typical design patterns are as follows:

• Creational patterns (5): Factory Pattern, Abstract Factory Pattern, Singleton Pattern, Builder Pattern, Prototype Pattern

• Structural patterns (7): Adapter Pattern, Bridge Pattern, Composite Pattern, Decorator Pattern, Facade Pattern, Flyweight Pattern, Proxy Pattern

• Behavioral patterns (11): Chain of Responsibility Pattern, Command Pattern, Interpreter Pattern, Iterator Pattern, Mediator Pattern, Memento Pattern, Observer Pattern, State pattern, Strategy Pattern, Template Pattern, Visitor Pattern

Object-orientation and databases

Main articles: Object-Relational impedance mismatch, Object-relational mapping, and Object database

Both object-oriented programming and relational database management systems (RDBMSs) are extremely common in software today[update]. Since relational databases don't store objects directly (though some RDBMSs have object-oriented features to approximate this), there is a general need to bridge the two worlds. There are a number of widely used solutions to this problem. One of the most common is object-relational mapping, as found in libraries like Java Data Objects and Ruby on Rails' ActiveRecord.

There are also object databases which can be used to replace RDBMSs, but these have not been as commercially successful as RDBMSs.

Matching real world

OOP can be used to translate from real-world phenomena to program elements (and vice versa). OOP was even invented for the purpose of physical modeling in the Simula-67 programming language. However, not everyone agrees that direct real-world mapping is facilitated by OOP, or is even a worthy goal; Bertrand Meyer argues in Object-Oriented Software Construction that a program is not a model of the world but a model of some part of the world; "Reality is a cousin twice removed". At the same time, some principal limitations of OOP had been noted.

However, Niklaus Wirth said of OOP in his paper "Good Ideas through the Looking Glass", "This paradigm closely reflects the structure of systems 'in the real world', and it is therefore well suited to model complex systems with complex behaviours."

Future of OOP

The future contains more standardization of functional programming techniques in OOP environments, particularly lambda expressions and closures, and more robust meta-programming constructs. Applying design patterns automatically through generic or meta programming techniques is an interesting area.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download