Assembly language is a small abstraction of the underlying machines.
Many so-called “imperative” languages that followed (such as FORTRAN, BASIC, and C) were abstractions of assembly language. Their primary abstraction still requires you to think in terms of the structure of the computer rather than the structure of the problem you are trying to solve. The programmer must establish the association between the machine model (in the “solution space,” which is the place where you’re implementing that solution, such as a computer) and the model of the problem that is actually being solved (in the “problem space,” pwhich is the place where the problem exists, such as a business). The effort required to perform this mapping, and the fact that it is extrinsic to the programming language, produces programs that are difficult to write and expensive to maintain, and as a side effect created the entire “programming methods” industry.
The alternative to modeling the machine is to model the problem you’re trying to solve. Early languages such as LISP and APL chose particular views of the world (“All problems are ultimately lists” or “All problems are algorithmic,” respectively). Prolog casts all problems into chains of decisions. Languages have been created for constraint-based programming and for programming exclusively by manipulating graphical symbols. (The latter proved to be too restrictive.) Each of these approaches may be a good solution to the particular class of problem they’re designed to solve, but when you step outside of that domain they become awkward.
The object-oriented approach goes a step further by providing tools for the programmer to represent elements in the problem space.We refer to the elements in the problem space and their representations in the solution space as “objects.”
OOP allows you to describe the problem in terms of the problem, rather than in terms of the computer where the solution will run.
These characteristics represent a pure approach to object-oriented programming:
Everything is an object. Think of an object as a fancy variable; it stores data, but you can “make requests” to that object, asking it to perform operations on itself. In theory, you can take any conceptual component in the problem you’re trying to solve (dogs, buildings, services, etc.) and represent it as an object in your program.
A program is a bunch of objects telling each other what to do by sending messages.
Each object has its own memory made up of other objects. You can build complexity into a program while hiding it behind the simplicity of objects.
Every object has a type. Using the parlance, each object is an instance of a class, in which “class” is synonymous with “type.” The most important distinguishing characteristic of a class is “What messages can you send to it?”
All objects of a particular type can receive the same messages.
Booch offers an even more succinct description of an object: An object has state, behavior and identity.
An object has an interface
An object provides services
In a good object-oriented design, each object does one thing well, but doesn’t try to do too much.
The hidden implementation
It is helpful to break up the playing field into class creators and client programmers.
In any relationship it’s important to have boundaries that are respected by all parties involved.
So the first reason for access control is to keep client programmers’ hands off portions they shouldn’t touch.
The second reason for access control is to allow the library designer to change the internal workings of the class without worrying about how it will affect the client programmer.
Access specifiers:
public means the following element is available to everyone.
The private keyword means that no one can access that element except you, the creator of the type, inside methods of that type.
The protected keyword acts like private, with the exception that an inheriting class has access to protected members, but not private members. 包内所有类可见，包外有继承关系的子类可见
Java also has a “ default” access. It is usually called package access because classes can access the members of other classes in the same package (library component), but outside of the package those same members appear to be private.
Reusing the implementation
Code reuse is one of the greatest advantages that object-oriented programming languages provide.
Because you are composing a new class from existing classes, this concept is called composition (if the composition happens dynamically, it’s usually called aggregation). Composition is often referred to as a “has-a” relationship, as in “A car has an engine.”
Composition comes with a great deal of flexibility. The member objects of your new class are typically private, making them inaccessible to the client programmers who are using the class. This allows you to change those members without disturbing existing client code. You can also change the member objects at run time, to dynamically change the behavior of your program. Inheritance, which is described next, does not have this flexibility since the compiler must place compile-time restrictions on classes created with inheritance.
Inheritance