Core Java Volume I-4.1. Introduction to object-oriented programming

4.1. Introduction to object-oriented programming
object-oriented Programming, or OOP for short, was the dominant programming paradigm these days, having replaced T He "structured," procedural programming techniques that were developed in the 1970s. Since Java is object-oriented, and you had to be familiar with the OOP to become productive with Java.

An object-oriented program is made of objects. Each object is a specific functionality, exposed to its users, and a hidden implementation. Many objects in your programs would be taken "off-the-shelf" from a library; Others'll be custom-designed.

whether you build a object or buy it might depend on your budget or On time. But, basically, as long as a object satisfies your specifications, you don ' t care how the functionality is implemented.

traditional structured programming consists of designing a set of procedures (or algorithms) to solve a problem. Once The procedures is determined, the traditional next step is to find appropriate ways to store the data. The the designer of the Pascal language, Niklaus Wirth, called his famous book on programming Algorithms + Data St Ructures = Programs (Prentice Hall, 1975). Notice in Wirth ' s title, Algorithms come first, and data structures come. This mimics the programmers-worked at that time. First, they decided on the procedures for manipulating the data; Then, they decided-what structure-impose on the data to make the manipulations easier. OOP reverses the order:puts the data first, then looks at the algorithms-operate on the data.

for small problems, the breakdown to procedures works very well. But objects is more appropriate for larger problems. Consider a simple web browser. It might require 2,000 procedures for their implementation, all of which manipulate a set of global data. In the object-oriented style, there might is a classes with a average of methods per class (see Figure 4.1). This structure was much easier for a programmer to grasp. It is also much easier to find bugs in. Suppose the data of a particular object is a incorrect state. It's far easier to search for the culprit among the methods that had access to that data item than among 2,000 procedu Res.
4.1.1. Classes
A class is the template or blueprint from which objects is made. Think about classes as cookie cutters. Objects is the cookie themselves. When you construct an object from a class, you is said to having created an instance of the class.

As you has seen, all code, the write in Java is inside a class. The standard Java Library supplies several thousand classes for such diverse purposes as user interface design, dates and calendars, and network programming. Nonetheless, in Java you still has to create your own classes to describe the objects of your application ' s problem domai N.

encapsulation (sometimes called information hiding) is a key Concept in working with objects. Formally, encapsulation is simply combining data and behavior in one package and hiding the implementation details from th E users of the object. The bits of data in an object is called its instance fields, and the procedures that operate on the data is called its m Ethods. A specific object is a instance of a class would has specific values of its instance fields. The set of those values is the current state of the object.
whenever you invoke a method in an object, it state may change.

The key to making encapsulation are to has methods never directly access instance fields in a class other than their Own. Programs should interact with object data is only through the object ' s methods. Encapsulation is the the-give an object it "black box" behavior, which is the key to reuse and reliability. This means a class could totally change how it stores it data, but as long as it continues to use the same methods to Manip Ulate the data, no other object would know or care.

When you start writing your own classes in Java, another tenet of OOP would make this easier:classes can is built by Exten Ding other classes. Java, in fact, comes with a "cosmic superclass" called Object. All and classes extend this class. You'll learn more about the Object class in the next chapter.

to work with OOP, you should be Able to identify three key characteristics of objects:

• The object ' s behavior-what can do with this object, or what methods can you apply to it?
• The object ' sstate-how does the object react when do you invoke those methods?
• The object ' s identity-how is the object distinguished from others, and the same behavior and state?

All objects is instances of the same class share a family resemblance by supporting the same behavior. The behavior of an object was defined by the methods so can call.

Next, each object stores information the what's it currently looks like. This is the object's state. An object's state could change over time, and not spontaneously. A change in the state of an object must is a consequence of method calls. (If an object's state changed without a method call on the that object, someone broke encapsulation.)

However, the state of an object does not completely describe it, because each object has a distinct identity. For example, under an order processing system, and both orders is distinct even if they request identical items. Notice the individual objects that is instances of a class always differ in their identity and usually differ in the IR state.

these key characteristics can influence each other. For example, the state of a object can influence its behavior. (If an order is "shipped" or "paid"), "it may reject a method call the asks it to add or remove items. Conversely, if an order was "empty"-that is, no items had yet been ordered-it should not allow itself to be shipped.)
4.1.3. Identifying Classes
in a Traditional procedural program, your start the process at the top, with the main function. When designing a object-oriented system, there is no "top," and newcomers to OOP often wonder where to begin. The answer is, identify your classes and then add methods to each class.

A simple rule of thumb in identifying classes are to look for nouns in the problem analysis. Methods, on the other hand, correspond to verbs.

For example, under an order-processing system, some of the nouns is

• Item
• Order
• Shipping Address
• Payment
• Account

These nouns may leads to the classes Item, Order, and so on.

Next, look for verbs. Items is added to Orders. Orders are shipped or canceled. Payments is applied to Orders. With all verb, such as "Add," "Ship," "Cancel," or "apply," identify, "the object," and the major responsibility for Carrying it out. For example, when a new item was added to an order, the order object should was the one in Charge because it knows how it stores and sorts items. That's, add should be a method of the Order class This takes an Item object as a parameter.

Of course, the "noun and verb" is but a rule of thumb; Only experience can help you decide which nouns and verbs is the important ones when building your classes.
4.1.4. Relationships between Classes
The most common relationships between classes is

• Dependence ("Uses–a")
• Aggregation ("Has–a")
• Inheritance ("Is–a")

the dependence, or "Uses–a" Relationship , the most obvious and also. For example, the order class uses the account class because Order objects need to access account objects to check for cred It status. The item class does not depend on the account class, because Item objects never need to worry about customer
accounts. Thus, a class depends on another class if it methods use or manipulate objects of the that class.
try to minimize the number of classes. The point was, if a class A is unaware of the existence of a class B, it was also unconcerned about any changes to B. (And T His means this changes to B does not introduce bugs into A.) In software engineering terminology, you want to minimize the coupling between classes.

the aggregation, or "Has–a" Relationship , is easy-to-understand because it is concrete; For example, an Order object contains Item objects. Containment means that objects of class A contain objects of class B.

the inheritance, or "Is–a" Relationship , expresses a relationship between a more special and a to general class. For example, the A Rushorder class inherits from the Order class. The specialized Rushorder class have special methods for priority handling and a different method for computing shipping CH Arges, but it other methods, such as adding items and billing, is inherited from the Order class. In general, if Class A is extends Class B, Class A inherits methods from class B but have more capabilities. (We describe inheritance more fully with the next chapter, in which We discuss this important notion at some length.)

Many programmers use the UML (Unified Modeling Language) notation-draw class diagrams that describe the relationships B Etween classes. You can see the example of such a diagram in Figure 4.2. You draw classes as rectangles, and relationships as arrows with various adornments. Table 4.1 shows the most common UML arrow styles.

Core Java Volume I-4.1. Introduction to object-oriented programming