Java Knowledge series 1

Programming language evolves always along with Compiler's evolvement

                                                                   JVM as Additional Indirection

Introduction to Object

  • Everthing 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. To make a request of an object, you “send a message” to that object. More concretely, you can think of a message as a request to call a method that belongs to a particular object.
  • Each object has its own memory made up of other objects. Put another way, you create a new kind of object by making a package containing existing objects. Thus, 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. This is actually a loaded statement, as you will see later. Because an object of type “circle” is also an object of type “shape,” a circle is guaranteed to accept shape messages. This means you can write code that talks to shapes and automatically handle anything that fits the description of a shape. This substitutability is one of the powerful concepts in OOP.
  • Booch offers an even more succinct description of an object: An object has state, behavior and identity.
  • An object has an interface: Creating abstract data types (classes) is a fundamental concept in object-oriented programming. Abstract data types work almost exactly like built-in types: You can create variables of a type (called objects or instances in object-oriented parlance) and manipulate those variables (called sending messages or requests; you send a message and the object figures out what to do with it).
  • The preceding diagram follows the format of the Unified Modeling Language (UML). An object provides services: While you’re trying to develop or understand a program design, one of the best ways to think about objects is as “service providers.”
    • Each class is represented by a box, with the type name in the top portion of the box,
    • any data members that you care to describe in the middle portion of the box,
    • and the methods (the functions that belong to this object, which receive any messages you send to that object) in the bottom portion of the box.
    • Often, only the name of the class and the public methods are shown in UML design diagrams, so the middle portion is not shown. If you’re interested only in the class name, then the bottom portion doesn’t need to be shown, either.
  • Thinking of an object as a service provider has an additional benefit: it helps to improve the cohesiveness of the object. High cohesion is a fundamental quality of software design: It means that the various aspects of a software component (such as an object, although this could also apply to a method or a library of objects) “fit together” well.
  • In a good object-oriented design, each object does one thing well, but doesn’t try to do too much.
  • Treating objects as service providers is a great simplifying tool, and it’s very useful not only during the design process, but also when someone else is trying to understand your code or reuse an object—if they can see the value of the object based on what service it provides, it makes it much easier to fit it into the design.
  • The hidden implementation: It is helpful to break up the playing field into class creators (those who create new data types) and client programmers (the class consumers who use the data types in their applications).
  • IOD(Interface-Oriented Design), Interface-Orented Programming
  • Keeps everything else hidden. Why? Because if it’s hidden, the client programmer can’t access it, which means that the class creator can change the hidden portion at will without worrying about the impact on anyone else. The concept of implementation hiding cannot be overemphasized.
  • Everything’s naked to the world.
  • The interface and implementation shall be clearly separated and protected. Thus you can change the internal working of the class without worrying about how it will affect the client programmer.
  • public means the following element is available to everyone.
  • The private keyword, on the other hand, means that no one can access that element except you, the creator of the type, inside methods of that type. private is a brick wall between you and the client programmer. Someone who tries to access a private member will get a compile-time error.
  • The protected keyword acts like private, with the exception that an inheriting class has access to protected members, but not private members.
  • Reusing the implementation: We call this “creating a member object.” Your new class can be made up of any number and type of other objects, in any combination that you need to achieve the functionality desired in your new class. 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.”, with the same lifecycle
  • Aggregation is often referred to as a "whole-part" relationship, with the different lifecycle


This UML diagram indicates composition with the filled diamond, which states there is one car.

 

  • Use inheritance as lessly as possible.Instead, you should first look to composition when creating new classes, since it is simpler and more flexible. If you take this approach, your designs will be cleaner.
  • You have two ways to differentiate your new derived class from the original base class. The first is quite straightforward: You simply add brand new methods to the derived class. The second and more important way to differentiate your new class is to change the behavior of an existing base-class method. This is referred to as overriding that method.
  • When dealing with type hierarchies, you often want to treat an object not as the specific type that it is, but instead as its base type. This allows you to write code that doesn’t depend on specific types.
  • The function call generated by a non-OOP compiler causes what is called early binding, static binding, compile-time binding.
  • In some languages you must explicitly state that you want a method to have the flexibility of late-binding properties (C++ uses the virtual keyword to do this). In these languages, by default, methods are not dynamically bound. In Java, dynamic binding is the default behavior and you don’t need to remember to add any extra keywords in order to get polymorphism.
  • In Java, Overloadding with same method name and different argument, Polymorphism with same method name and same argument.
  • In C++, if one method defined in based class is redefined in derived class with same name and different argument, it will hide all methods with same name in based class when visiting this method by a object of derived class.
  • We call this process of treating a derived type as though it were its base type upcasting. The name cast is used in the sense of casting into a mold and the up comes from the way the inheritance diagram is typically arranged, with the base type at the top and the derived classes fanning out downward.
  • That is, you don’t want anyone to actually create an object of the base class, only to upcast to it so that its interface can be used. This is accomplished by making that class abstract by using the abstract keyword. If anyone tries to make an object of an abstract class, the compiler prevents it. This is a tool to enforce a particular design.
  • The interface keyword takes the concept of an abstract class one step further by preventing any method definitions at all. The interface is a very handy and commonly used tool, as it provides the perfect separation of interface and implementation.
  • There are different philosophies at work here. C++ takes the approach that control of efficiency is the most important issue, so it gives the programmer a choice. For maximum run-time speed, the storage and lifetime can be determined while the program is being written, by placing the objects on the stack (these are sometimes called automatic or scoped variables) or in the static storage area. This places a priority on the speed of storage allocation and release, and control of these can be very valuable in some situations.
  • The second approach is to create objects dynamically in a pool of memory called the heap.
  • Object-oriented programming is often summarized as simply “sending messages to objects.”

 

原文地址:https://www.cnblogs.com/iiiDragon/p/3227103.html