Results 1 to 1 of 1
  1. #1
    Java Exam is offline Member
    Join Date
    Dec 2011
    Posts
    64
    Rep Power
    0

    Default Tutorial: Review of Object Oriented Programming for the Java Certification Exam

    In this article, we will review the underlying paradigm of Java, Object Oriented Programming. We will explore the key principles of object oriented programming such as objects, inheritance, encapsulation and other principles that are used in modeling the systems implemented in Java. This is part of a larger series of articles to help you prepare for the java associate exam.

    Objects

    Java is an object-oriented language that lets programmers develop software by through the implementation of objects and their relationships. The relationships are defined within the objects, so the objects are the central focus of any software development effort in Java.

    In an object oriented language like Java, an object is an instance of a class or the class itself for static classes or a singleton where there is only one instance. The class is the definition for an instance, and a particular item defined by that class is an instance. If we have a class that defines documents (i.e. title, author, and so on), then an object that describes a particular document is an instance. Usually, an object is a software object that represents some important part of the system. Sometimes, these objects correspond to actual physical items such as cargo software might have a class that represents cargo containers, and each instance of that class corresponds to a real cargo container somewhere in the world.

    Often, instead these objects in software define abstract items that don't really exist. For example, the Math class defines a constant for pi that doesn’t relate to a physical item although it might seem real. There are things that are even less abstract than a mathematical constant that come up in software development. That's because object-oriented languages such as Java let us define purely abstract objects, such as a Shape class. In many shape-related systems, Shape itself can never be instantiated. Instead you must instead create an instance of some other class that extends Shape such as a Circle or Rectangle class. And sometimes an abstract class extends another abstract class, making for layers of abstraction.

    Consider some other examples of objects that have been developed for one system or another:
    • A class that handles button clicks
    • A class that contains information about a three-dimensional structure (such as a pyramid or sphere)
    • A class that contains that describes a paragraph within a document (font style, font size, and so on)
    • A class that defines a print job (such as gets created when you click Print in a word processor)

    All objects in Java are classes. Enumerations are a special kind of class since each enumeration has an implicit class provided by the compiler. Java also has primitives and interfaces, but primitives and interfaces are not objects. Primitives define values, but they aren't objects. We will examine why neither primitives nor interfaces are objects shortly. Remember that a Java object is an instance of a class, and a class is code that defines something useful. Even an abstract class defines something useful, though it relies on the classes that extend it to provide the remaining information.



    Object-oriented languages supports three key important fthrustures:
    • Encapsulation
    • Inheritance
    • Polymorphism

    We will review each one of these fthrustures.

    Encapsulation

    Encapsulation means that an object holds its contents in such a way that its contents are hidden from other objects dep(though we have a number of ways to provide access to the contents of a class). That way, one object's contents can't get tangled up with the contents of another object. Given that an Airplane can have thousands of classes, keeping the various bits and pieces of all those classes separate is a really good idea. Otherwise, we'd never be able to find anything.

    One of the key concerns of a Java developer when crthrusting or modifying class is to figure out which parts to make visible to other classes. A related, concern is which classes get to see and possibly modify the contents of the current class. As that implies, you can make part of a class visible to just a select group of classes rather than all other classes. The mechanics of access modifiers will be covered later.

    Inheritance

    Inheritance defines relationships between the classes as well as between the objects of an object- oriented system. All classes in Java have some other object as a parent. Generally this is the class Object. In Java one object extends another and there is always some object that starts it all. That special object (the only one that has no parent) is a class called Object. All other Java objects are descendants in one way or another of the class Object.

    Let's consider an example from the field of Aircraft. If we want to represent certain Aircraft (in particular, Amphibious, Propeller Aircraft, Helicopter and Racing Aircraft). They're all Aircraft, so we might start with a class called Aircraft. Then we have three more classes called Helicopters, Amphibious, and Propeller. Each of those classes extend the Aircraft class. There are substantial differences among Helicopters, Amphibious, and Propeller, and we look at modeling their differences when we get to Polymorphism.

    Multiple Inheritance

    Java does not support multiple inheritance. Instead it uses interfaces to provide most of the benefits of multiple inheritance without the one big problem that comes with inheritance. That is, an object in Java cannot extend more than one parent object whereas in other languages such as C++ permit inheriting from more than one parent. The designers of Java determined that Java could be made without that level of complexity.
    The key problem with multiple inheritance is that a single class can extend two other classes, and those two classes might in turn extend the same ancestor class. Your code would not know which ancestor class provides the right information. This is sometimes called “the diamond problem,” because it looks like a diamond when graphed as shown below:

    Tutorial: Review of Object Oriented Programming for the Java Certification Exam-d11-diamondproblem.jpg
    Figure: The Diamond Problem

    The diamond problem appears easy to avoid, however, since most software is created by multiple teams of people it's not hard to imagine how one team might implement a class that extends a class and the other team extends the same class, and then if we had multiple inheritance, someone in the client teams might try to extend both and run right into the diamond problem. It's easy to get into a situation where a single method might extend methods from two other classes. The compiler would not know which method we meant to use. Java prevents all that by not providing multiple inheritance.

    But Java does provide a way to get most of the benefits with very few of the problems from multiple inheritance. You can include instances of other classes as fields within your class. That way, your class can access the public or package, fields and methods within those classes. You could access the private bits and because you can't include abstract classes, you're well protected from getting into problems that arise from having more than one ancestor. This technique is sometimes called composition, because your new class is composed, in part, of the publicly available bits of other classes. Best practice in object oriented programming is to use composition instead of inheritance.

    Modeling Behavior through Interfaces

    Java includes the concept of interfaces. An interface is a set of methods or things that an object can do or that an object must have if it uses the keyword in Java for implementing that interface. In particular, a class that implements an interface must implement all the methods within that interface. Let's return to our three concrete classes: Helicopter, Amphibious, and Propeller.

    Helicopters are a type of aircraft characterized by the lift and thrust being supplied by engine-driven rotors. Amphibious aircraft are aircraft that can take off and land on both land and water. The Bombardier 415 and Cessna Caravan are amphibious aircraft that are still in production. We could therefore create a set of interfaces to model the behavior of these aircraft landing on both land and water. We have the following interfaces: LandLanding and WaterLanding.

    Abstract Classes

    There are times a Java developer writes a class that should never be instantiated. It's a class that will never have an object associated with it. These type classes usually serves as the basis for other classes. Our Aircraft class is an example of such a class. All the Aircraft in the real world are specific types of Aircraft rather than just Aircrafts. Amphibious Aircrafts, Propeller Aircrafts, Helicopters, and so on are all types of Aircraft with more specific names and more specific traits. So, there's no actual aircraft that's a generic Aircraft. Consequently, we don't want anyone to create an instance of our Aircraft class, because that would be bad modeling.

    Java lets developers declare that a class should never have an instance by using the abstract keyword. In Java, abstract means that the class can still be extended by other classes but that it can never be instantiated (turned into an object). Returning to our example, we can have Aircraft be abstract (because there's no such thing as a generic Aircraft) and still have Amphibious Airplane, Propeller Airplane and Helicopters extend Aircraft (because Amphibious Airplane, Propeller Airplane and Helicopters are Aircraft).

    The hard part is figuring out when a class should be abstract. Modeling the aircraft type is a simple example, so it's not hard to see that Aircraft should be an abstract class.

    The opposite of an abstract class is usually called a concrete class. Concrete classes are the default, so there's no keyword for it. In most programs, most classes are concrete classes.

    Methods in Abstract Classes

    Abstract classes can include abstract methods. Any class that extends a class with an abstract method must implement that method. For example, our Aircarft class includes an abstract fly() method. Any class that extends Aircraft must implement the fly method, and that implementation must have the same signature. So, in this case, the implementations must return void and accept no arguments.

    Abstract classes can also include regular methods that their descendant classes can use without needing to implement them. The listing below shows both kinds of methods within the Aircraft class:

    Java Code: Methods within an abstract class
    package com.acme.example.aircraft;
    abstract class Aircraft { 
       // And here's a method for flying. 
       // Each child class must implement it. 
       abstract void fly();
    
       // All descendant classes can call this and do 
       // not need to implement their own versions of it 
       protected void whatAmI() {
          System.out.println("I am a Aircraft");
       }
    }
    That's a trivial method, but it raises an interesting point. Classes that extend the Helicopter class might also have methods with the same signature. Those methods are said to override this method. For example, the Helicopter class might have a whatAmI method of its own. Let's suppose it was identical but printed “I am a Aircraft” to System.out. Then, to use the Aircraft class's method, we'd have to use the super keyword, as shown in the listing below:

    Java Code: The Aircraft class with an overridden whatAmI method
     package com.acme.example.aircraft;
    class Aircraft extends Aircraft {
       // implement the super class's abstract methods
       private static int numberOfAircraft; Aircraft() {
          numberOfAircrafts++; 
       }
    
       public static final int getNumberOfAircrafts() {
          return numberOfAircrafts;
       }
    
       @Override 
       protected void whatAmI() {
          System.out.println("I am an Aircraft");
          super.whatAmI();
       }
    }
    This is a trivial example, but I hope it gives you a sense of how you can use the characteristics of both a base class and a child class to provide meaningful information and other functionality for your users. The trick is knowing which objects to put at which level. One rule of thumb is to put each object as high in your class hierarchy as you can. That's whyI define the speak method at the Aircraft level but implement it at the individual aircraft level.

    Static Members

    Classes can have static members, including fields, methods, and other classes (a class within a class is called an inner class). A static member of a class is often called a class member. The important thing to know about class members is that only one instance of that member ever exists. If our Aircraft class has a static method, we might have ten different instances of the Aircraft class, but there would only ever be one of that static method. That becomes an issue when each of the members of the Aircraft class want to use that method. The instances end up waiting for each other.

    Static members have their uses, though. When you want to be certain that only one of something exists for all the objects that instantiate a particular class, the static keyword is how you do it. One obvious use of the static keyword is on the main method. Imagine if every instance of a program class could start a new program. We would quickly swamp the operating system with programs. A more common and useful use of static members is to implement counters. Suppose we want to keep track of how many Aircraft objects we create. The Aircraft class could then include a static field called numberOfAircrafts, and the constructors for the class would increment that field every time we create a Aircraft object. That code would look something like the Aircraft class in Listing 6-4.

    Java Code: Counting Aircraft objects
    class Aircraft extends Aircraft{
       private static int numberOfAircrafts;
    
       Aircraft() {
          numberOfAircrafts++;
       }
    }
    To get the number of Aircraft objects, we can either implement a method to return the value or we can reference the field and get its value. To reference a static member, we use the name of the class separated from the static member's name by a period, as shown in listing below.

    The listing below references a static member System.out.println(Aircraft.numberOfAircrafts);

    However, we should generally prefer the idiom of making the static field private and crthrusting a get method to return that value. Otherwise, we expose the field for other classes to set, and that is probably a bug. The listing below shows the Aircraft class modified to use the private field pattern (patterns are common idioms in computer science—there are many of them, and they are a worthwhile thing to study if you pursue programming).

    Java Code: The Aircraft class with a private static field class
    Aircraft extends Aircraft{
    
       private static int numberOfAircrafts;
       Aircraft() {
          numberOfAircrafts++; 
       }
    
       public static final int getNumberOfAircrafts() {
          return numberOfAircrafts;
       }
    }
    Do you notice that the method is also static? We need only one such method, regardless of how many Aircraft objects we create, so it makes sense for getNumberOfAircrafts to be static. We also make it final, because there's no reason for child classes to implement their own getNumberOfAircrafts methods. Thus, if we have Tiger and Lion classes extending the Aircraft class, they could not have getNumberOfAircrafts methods unless those methods have different arguments.

    Polymorphism

    Polymorphism, from the Greek poly, for many, and morph, for form, means that the same thing can have different forms. It's a technical term in many fields, including chemistry, biology, and (of course) computer science. Each field defines it in terms relevant to that field of study, but it all boils down to having multiple forms.

    In object-oriented computer languages, one kind of polymorphism is the ability of different classes to respond appropriately to the same input. So, our Aircraft class might define a speak method. The Aircraft class would implement the speak method as a meow, the Amphibious as a bark, and the mouse as a squeak. They all implement the same method, but they each do it in their own appropriate way. These methods are said to be overridden. The methods in the child class replace the behavior of the parent class with their own behavior—that is, they override the parent's method.

    Another kind of polymorphism (called overloading) is having the same behavior mean something different depending on the object passed to the behavior (or method). For example, our Aircraft object might have two methods called chase, and an instance of Aircraft would exhibit different behavior for the chase(Tail) method and the chase(Propeller) method. That is, we have methods of the same name, but they have different signatures (one takes a Tail object as its argument and one takes a Propeller object). That's a classic example of method overloading.

    Our Aircrafts in Java

    The listing shows an incomplete definition of the aircraft classes used as examples earlier in the chapter. When a developer writes this kind of code, the developer is “crthrusting stubs” or “writing stubbed out code.” A stub means that we created the structure but have left at least some of the details for another time or for someone else to do.

    You should put your code in packages. That way, the code in one package won't interfere with the code in other packages. If you put everything in the default package, you soon run into the problem of wanting to call a class or interface by a name you already used. I suggest you get in the habit of putting all your code into packages. The package used throughout this chapter includes a Lift interface. Imagine if want another object model that defined Lift drones (the remote-control aircraft made famous in recent wars). That's exactly the kind of entanglement that makes packages so useful. So we add a package definition for each class and interface. In this case, they are in the same package.

    Java Code: The finished Aircraft class
    package com.acme.example.aircraft;
    
    abstract class Aircraft { 
       // And here's a method for flying. 
       // Each child class must implement it. 
       abstract void fly();
    
       // All descendant classes can call this 
       // and do not need to implement their own versions of it 
       protected void whatAmI() {
          System.out.println("I am a Aircraft");
       }
    }
    The Aircraft class serves as the basis for our other classes. As we discussed previously, we never want to instantiate a Aircraft object, so it's abstract. It also has an abstract method, so every class that extends Aircraft has to implement a speak method with the same signature (returns void and accepts no arguments). Finally, it includes an ordinary method, which descendant classes can use. This is shown in the listing below:

    Java Code: The finished Helicopter class
    package com.acme.example.aircraft; 
    class Helicopter extends Aircraft implements Lift, Thrust {
       private static int numberOfHelicopters; 
    
       Helicopter() {
          numberOfHelicopters++;
       }
     
       public static final int getNumberOfHelicopters() {
          return numberOfHelicopters;
       }
    
       @Override 
        protected void whatAmI() {
           System.out.println("I am a Helicopter"); 
           super.whatAmI();
        }
    
        // implement the super class's abstract methods 
        @Override 
        void fly() {
            lift();
            Thurst newThrust = new Thrust();
    	 thrust(newThrust);
            System.out.println("With lift and thrust the helicopter flies"");
        }
    
        // Implementation of overridden function
        void fly(Direction direction) {
            // fly in this direction 
        }
    
        // methods for the Lift interface 
        @Override 
        public void lift() {
           // go lifting
        }
    
        // methods for the Thrust interface 
        @Override 
        public void thrust (Object newThrust) {
           // thrust fresh newthurst
        }
    }
    Because we use the Aircraft class throughout the earlier examples, you already know it extends the Aircraft class. As we discussed in the “Modeling Behavior through Interfaces” section, it also implements the Lift and Thrust interfaces. After all, Aircrafts are Lifts and Thrusts as shown in the listing below:

    Java Code: The finished Amphibious class
    package com.acme.example.aircraft;
    class Amphibious extends Aircraft implements Lift, Thrust, WaterLanding { 
       // implement the super class's abstract methods 
       @Override void fly() {
          System.out.println("The Amphibious airplane in flight");
       }
    
       // methods for the Lift interface 
       @Override 
        public void lift() {
           // go lifting
        }
    
        // methods for the Thrust interface 
        @Override 
        public void thrust (Object newThrust) {
           // thrust fresh newthurst
        }
    
        // methods for the WaterLanding interface 
        @Override 
        public void waterLanding (Object landingEquipment, boolean activate) {
           if (activate) { 
              // set landing surface for water if needed
           } else {
               // no activation needed to land on water
          }
       }
    }
    The Amphibious class also extends Aircraft and implements the Lift and Thrust interfaces as well as the WaterLanding interface. Next let's look at an airplane that is still a Aircraft but that has different behaviors: a propeller aircraft. The listing below defines our Propeller object:

    Java Code: The finished Propeller class
    package com.acme.example.aircraft;
    class PropellerAirplane extends Aircraft implements Propeller{ 
       // implement the super class's abstract methods 
       @Override 
       void speak() {
          System.out.println("The mouse says, \"squeak.\"");
       }
    
           // methods for the Propeller interface 
       @Override 
       public void thrust (Object Propeller) {
          // thrust Propeller
       }
    }
    As with our other aircraft objects, the Propeller class extends Aircraft. However, this type of plane doesn’t land on water and uses a propeller for flight. So a PropellerAirplane makes use of the Propeller interface to implement thrust using a propeller. Let’s look more in depth at the interfaces. We start with the Lift interface shown in the listing below:

    Java Code: The Lift interface
    package com.acme.example.aircraft;
       interface Lift { 
          public void lift();
    }
    All Lifts lift, so our Lift interface includes a lift() method. Any class that implements this Lift interface must implement a lift() method with the same signature (void and with no arguments). If we have a Drone class that implements a Lift interface, that interface might implement a launch (Missile hellfire) method, which is different from a Lift interface that suits airplane. Next we have the Thrust interface, shown in the listing below:

    Java Code: The Thrust interface
    package com.acme.example.aircraft;
    interface Thrust {
       public void thrust(Object newThrust);
    }
    The Thrust interface has a thrust method that takes a an object named newThrust as the argument to the interface's only method. Next we look at the WaterLanding interface, shown in the listing below:

    Java Code: The WaterLanding interface
    package com.acme.example.aircraft;
    interface WaterLanding {
       public void waterLanding (Object landingEquipment, boolean activate);
    }
    WaterLandings are used for aircraft to land on any body of water they find beneath them with the equipment needed . This is relevant for amphibious aircraft. One issue is that some types of aircraft require landing equipment to be activated therefore we include a boolean argument for activating the landing equipment. Finally, we show a program class, called Airport, that lets our aircraft take off and land in the listing below:

    Java Code: Getting all aircraft flying
    package com.acme.example.aircraft; public class Airport {
    
       public static void main(String[] args) { 
          // launch instances of the aircraft 
          Helicopter helicopter = new Helicopter(); 
          Amphibious amphibious = new Amphibious();
          Propeller propeller = new Propeller();
    
          // get the aircraft flying
          helicopter.fly(); 
          amphibious.fly(); 
          propeller.fly();
       }
    }
    As you can see, all it does is creates an instance of each type of aircraft and then have each one fly off.

    Learning about Granularity

    The number of classes and interfaces might seem like a lot of objects to for aircraft to fly off and land in an appropriate on proper terrain. Generally if you are writing a program that only produces three lines of text, it would be more appropriate to just write one class. But what we have done here is only for demonstrative purposes in order to show how to model a relatively simple system made up of different types of aircraft in Java.

    If we were really writing a system to model the different types of aircraft, then we would need to have many more classes. For example, if I were modeling aircraft, we would not pass generic objects to the thrust methods. We would create an abstract class called Fuel and concrete classes called Liquid Oxygen and Hydrogen, Petrol, etc.

    If you “chunk up” your program into as many classes and interfaces as possible, you gain two things:
    • Extensibility
    • Maintainability

    Extensibility means that you can easily make your program do more than it does now. In the case of our aircraft program, we could quickly add more aircrafts and make those aircrafts do more things (such as lift off, accelerate, decelerate, and land). If we expand the program, we might also expand the fuel details such that the Aircraft class has Liquid Hydrogen and Oxygen subclasses.

    Maintainability relates to the ability to find the error in your code that is wrong. If all your code is in located in only a few classes or possibly one class, it will be more difficult to figure out the problem. Sure, the debugger gets you to the right line, but you won't know whether the problem is in your definition of an aircraft or your definition of a Aircraft or your definition of its behavior (such as Lift or Amphibious). Making multiple classes and interfaces greatly aids debugging because you can see which piece holds the problem spot. In other words, granularity makes it easier to detect error- free programs. Real programs need granularity, and good programmers work to achieve it.

    Pass-by-Reference and Pass-by-Value

    Pass-by-reference and pass-by-value refer to how information is passed from one object to another. Nearly all of the passing of information in Java goes through methods, but information can also go through fields within an object.

    Java normally uses only pass-by-value. However, the values it passes differ greatly based on what is passed. For primitives, Java passes a copy of the primitive (i.e. the method receives a copy of the primitive - say an int, not the original int). For objects, Java passes a pointer. A pointer is the address of an object in memory. This subtle difference trips up many novice Java developers. In the listing below are a couple of examples to help clarify the issue.

    Java Code: Pass-by-reference and pass-by-value
    package com.acme.examples.hello; public class IntegerWrapper {
    public int objectInt = 0;
    } 
    
    package com.acme.examples.hello; 
    public class Hello {
       static int primitive Int = 0; 
       static IntegerWrapper intWrapper = new IntegerWrapper();
    
       public static void main(String[] args) throws Exception { 
          passBy(primitive Int, intWrapper); 
          System.out.println("primitive Int = " + primitive Int +"; 
          intWrapper.objectInt = " + intWrapper.objectInt);
       }
    
       public static void passBy(int primitive Int, IntegerWrapper intWrapper) { 
          primitive Int++; 
          intWrapper.objectInt++;
       }
    }
    This listing shows a program that has two classes, IntegerWrapper and PassByTest. IntegerWrapper turns a primitive into an object (this is actually poor programming but is done strictly to make this illustration as simple as possible). PassByTest demonstrates pass- by-reference and pass-by-value. When we run PassByTest, its output is primitive Int = 0; intWrapper.objectInt = 1.

    When you pass a primitive to a method, the JVM preserves the original value and makes a new primitive (i.e. a copy) with the same value for use in the method. The JVM consequently has two values, the original primitive Int field in PassByTest and the primitive Int argument to the passBy method. As the JVM makes a new primitive, the original never gets modified.

    Even if the passBy method returned the primitive value, it would not change the original value. Unless we decide to re-assign the original value, it remains whatever it was originally set to (in our case, this is 0). If we assign the return value of the method to the original primitive, there is no problem. We will simply have two different values, and we assign the value of the new one (done by the method) to the old one. Consider the modified PassByTest class in the listing below:

    Java Code: PassByTest with a return value for the passBy method
    package com.acme.examples.hello; 
    public class Hello {
    
       static int primitive Int = 0; 
       static IntegerWrapper intWrapper = new IntegerWrapper();
    
       public static void main(String[] args) throws Exception { 
          passBy(primitive Int, intWrapper); 
          System.out.println("primitive Int = " + primitive Int + 
                "; intWrapper.objectInt = " + intWrapper.objectInt);
    }
    
          public static int passBy(int primitive Int, IntegerWrapper intWrapper) { 
          primitive Int++; 
          intWrapper.objectInt++; 
          return primitive Int;
       }
    }
    The passBy method now returns an int, but the output remains the same (primitive Int remains 0). I know we have hammered the point repeatedly, but, again, primitive Int in the method is a different primitive than the primitive Int field in the class. Remember, the compiler makes a copy of it when it calls the method.

    Now, let's look at what happens to IntegerWrapper.objectInt. Because IntegerWrapper is an object, the value that gets passed is its address in memory (that is, a pointer to the object). There's only one IntegerWrapper object, named intWrapper, in memory (because we used the new keyword with that class only once). So, any work done on intWrapper is done to the same object. Consequently, when we increment intWrapper.objectInt, the change makes it back to the main method, because the main method still looks at the same spot in memory. That is, intWrapper continues to be at the same reference in memory, and so we change that object where we could not change a primitive.
    Initially it may seem confusing, but over time, you come to recognize it. Consider references a bit like remote controls that you can use and the actual object that it controls as being either a television or hi-fi system. It's a tricky concept, but you have to master it to be able to program in Java (and many other languages).

    There is a very specific reason for to pass objects by reference. Consider if you have a complex object that might have several fields, and many of those fields might themselves be references to other objects (remember the composition technique), and so on, to any depth you can imagine (i.e. object stacks, as such things are called, are often many layers deep). What exactly is the value of such an object, and how much memory and processing time gets chewed up trying to make a temporary copy for every method that gets that object as an argument? And what happens if we use such an object recursively (that is, the object can modify itself)? If you think about those issues for a minute, you will quickly understand the value of why objects are passed as references (that is, as memory addresses). Otherwise, Java programs would be substantially harder to manage and perform more poorly than they could.

    Summary

    There are numerous books that have been written on object modeling. It's the most fundamental part of object-oriented programming, and one must be vigilant in order to avoid falling into bad practices. Mastering object modeling requires both experience and study: experience to see how object models actually work and study to be aware of the issues. We have only presented one simple example (using some types of aircraft for demonstration purposes), but this is in no way a complete treatment of object modeling.

    We have looked at the use of abstract classes, static and final methods, and static fields. And we have looked at the rationale for making fields private with get methods rather than having the field be visible outside the class.

    We have also looked into the value of granular programming (also known as “chunking” and modularity). Keep in mind that it is important to “chunk up” your programs into classes and interfaces, by grouping similar things or aspects of your program in order to make them easier to understand and to debug when problems arise.

    Finally, we looked in depth at the theoretical issues related to pass-by-reference versus pass-by-value. Specifically, we learned that Java is strictly pass-by-value. However, some of those values are pointers (i.e. memory addresses at which objects reside) that consequently when modifying an object that has been passed modifies the original object. In contrast, modifying a primitive modifies only a local copy of the primitive rather than the original.
    Attached Thumbnails Attached Thumbnails Tutorial: Review of Object Oriented Programming for the Java Certification Exam-d11-diamondproblem.jpg  

Similar Threads

  1. Replies: 0
    Last Post: 05-05-2012, 02:36 PM
  2. Replies: 0
    Last Post: 05-03-2012, 12:55 AM
  3. Replies: 0
    Last Post: 05-02-2012, 11:23 AM
  4. Replies: 0
    Last Post: 04-05-2012, 04:19 PM
  5. Replies: 0
    Last Post: 03-12-2012, 02:12 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •