[ Pobierz całość w formacie PDF ]
.Because other objects must communicate with the object only through its interface, the internal portion of the object is protected from outside tampering.And because an outside program has no access to the internal implementation of an object, the internal implementation can change at any time without affecting other parts of the program.So, you've learned that encapsulation provides two primary benefits to programmers:lImplementation hidingllModularitylImplementation hiding refers to the protection of the internal implementation of an object.An object is composed of a public interface and a private section that can be a combination of internal data and methods.The internal data and methods are the sections of the object hidden.The primary benefit is that these sections can change without affecting other parts of the program.Modularity means that an object can be maintained independently of other objects.Because the source code for the internal sections of an object is maintained separately from the interface, you are free to make modifications with confidence that your object won't cause problems.This makes it easier to distribute objects throughout a system.MessagesAn object acting alone is rarely very useful; most objects require other objects to do much of anything.For example, the car object is pretty useless by itself with no other interaction.Add a driver object, however, and things get more interesting! Knowing this, it's pretty clear that objects need some type of communication mechanism in order to interact with each other.Software objects interact and communicate with each other through messages.When the driver object wants the car object to accelerate, it sends the car object a message.If you want to think of messages more literally, think of two people as objects.If one person wants the other person to come closer, they send the other person a message.More accurately, they may say to the other person “Come here, please.” This is a message in a very literal sense.Software messages are a little different in form, but not in theory—they tell an object what to do.Many times the receiving object needs—along with a message—more information so that it knows exactly what to do.When the driver tells the car to accelerate, the car must know by how much.This information is passed along with the message as message parameters.From this discussion, you can see that messages consist of three things:lThe object to receive the message (car)llThe name of the action to perform (accelerate)llAny parameters the method requires (15 mph)lThese three components are sufficient information to fully describe a message for an object.Any interaction with an object is handled by passing a message.This means that objects anywhere in a system can communicate with other objects solely through messages.So you don't get confused, understand that “message passing” is another way of saying “method calling.” When an object sends another object a message, it is really just calling a method of that object.The message parameters are actually the parameters to a method.In object-oriented programming, messages and methods are synonymous.Because everything that an object can do is expressed through its methods (interface), message passing supports all possible interactions between objects.In fact, interfaces allow objects to send and receive messages to each other even if they reside in different locations on a network.Objects in this scenario are referred to as distributed objects.Java is specifically designed to support distributed objects.ClassesThroughout this discussion of object-oriented programming, you've only dealt with the concept of an object already existing in a system.You may be wondering how objects get into a system in the first place.This question brings you to the most fundamental structure in object-oriented programming: the class.A class is a template or prototype that defines a type of object.A class is to an object what a blueprint is to a house.Many houses may be built from a single blueprint; the blueprint outlines the makeup of the houses.Classes work exactly the same way, except that they outline the makeup of objects.In the real world, there are often many objects of the same kind.Using the house analogy, there are many different houses around the world, but houses all share common characteristics.In object-oriented terms, you would say that your house is a specific instance of the class of objects known as houses.All houses have states and behaviors in common that define them as houses.When a builder starts building a new neighborhood of houses, he typically builds them all from a set of blueprints.It wouldn't be as efficient to create a new blueprint for every single house, especially when there are so many similarities shared between each one.The same thing goes in object-oriented software development; why rewrite tons of code when you can reuse code that solves similar problems?In object-oriented programming, as in construction, it's also common to have many objects of the same kind that share similar characteristics.And like the blueprints for similar houses, you can create blueprints for objects that share certain characteristics.What it boils down to is that classes are software blueprints for objects.As an example, the car class discussed earlier would contain several variables representing the state of the car, along with implementations for the methods that enable the driver to control the car.The state variables of the car remain hidden underneath the interface.Each instance, or instantiated object, of the car class gets a fresh set of state variables.This brings you to another important point: When an instance of an object is created from a class, the variables declared by that class are allocated in memory.The variables are then modified through the object's methods.Instances of the same class share method implementations but have their own object data.Where objects provide the benefits of modularity and information hiding, classes provide the benefit of reusability.Just as the builder reuses the blueprint for a house, the software developer reuses the class for an object
[ Pobierz całość w formacie PDF ]
