HD Pg 227, Sec. 8.8.0 - exercises

[OCAJO1]

I don't get what question 2 of this exercise section going for, is it to show that different return types have no effect on overloaded methods' signature?

[admin]

Yes, return types, formal parameter names, throws clause, access modifiers.

[OCAJO1]

Combined with the next entry.

[OCAJO1]

Question 2 of exercises in section 8 - So the correct answer to this question would be to change the method's name.

Question 5 of exercises in section 8 -
Two questions,
1. Is there a more streamlined code than what I did to answer this question?
2. "After returning back to method1, print the values again. Explain the output." Is asking to explain about the fact that variables updated with different objects print different results, except for the static variable that is the same variable that is changing, regardless of in which method is updated?

Code: Select all

Package 1;
import static student.Student.*;
import student.*;

Class TestClass{
    Student method1(){
        
        Student s = new Student();
        s.studentId = 20;
        name = "Jack";
        s.address = "12 main street";
        
        System.out.println(name);
        System.out.println(s.studentId);
        System.out.println(s.address);

        return s;   
    }    
    
    void method2(Student y){
             
        System.out.println(name);
        System.out.println(y.studentId);
        System.out.println(y.address);
        
        Student z = new Student();
        z.studentId = 40;
        name = "Jill";
        z.address = "24 Right street";
        
        System.out.println(name);
        System.out.println(z.studentId);
        System.out.println(z.address);
    }

    public static void main(String[] args) {
        
       TestClass d = new TestClass();
       d.method2(d.method1());
       d.method1();
    }
}

package 2;
Public class Student{

    public int studentId;
    public static String name;
    public String address;
    
    static {name = "Jim";} //just testing static initialization 

    public static void main(String[] args) {
        Student s = new Student();
        s.studentId = 345;
        name = "James";
        s.address = "234 madison Ave"; 
    }
}[code]

Question 6 of exercises in section 8 -
Two questions,
1. Would a constructor (i.e. student (Object x){ } ) with an Object parameter be a good design for constructor that accepts values for all of class' instance fields?
2. Unless the second part of the question is aiming to use a constructor like a method (i.e. this.studentId = 1), how would no-arg constructor use its super-constructor with a parameter to access incoming fields?

Question 7 of exercises in section 8 - Since there is no mention of sub-class, the only access modifier that will allow access to student class' fields, would be public, or am I missing something?

Thanks

[admin]

1. yes.
2. In main, I would do:
Student s = new Student();
method1(s);
method2(s);
//print values again

But it's not that important. You got the point.

3. No, the constructor should take separate arguments - one for each of its instance field. e.g. Student(int id, String fName, String lName).
The exercise is not talking about super constructor but chaining a constructor -
Student() //no args constructor
{
this(0, "Dummy", "LastName");
}

4. Yes, Student fields must be public if a class in another package has to access them.

[OCAJO1]

2. That brings up the question, is it ever a good design in Java to write d.method2(d.method1()); type of method calling code?

3. This bring up two more questions,
3.1. Designing it this way, doesn't it make the constructor hard coded? What if a need for a fourth variable comes up later and what will happen to other classes accessing this class' method(s)?
3.2 Doing it by means of chaining would solve the problem of the constructor with parameters having been activated already, so the constructor with no argument calling it would not fail. I'm trying to make sure that I have it clear, do I?

Thanks

[admin]

2. I find it awkward but I don't like the words "ever" and "never". This is too subjective.
3.1 No, I don't think it is hardcoding at all. You may google more about what constitutes harcoding. You can always add a fourth constructor with the fourth parameter. Have the previous constructor call the new constructor using this(p1, p2, p3, dummyvalue);
But if your class has actually changed too much because of the 4th parameter, then the classes using your class will be affected anyway.
3.2 Yes, you can read more about the Builder pattern.

FYI, this discussion is all beyond OCAJP scope though.

[OCAJO1]

2. Come to think of it, is like those who favor multiple if-else design vs. those who consider more than three if-else deep, not being a good design?

3.1 Maybe hardcoding was too harsh of a classification. But would it be correct to say that introduction of a new constructor (i.e. with a 4th parameter), and having it call the constructor with 3 parameters, is the way to get around effecting other classes which have been using the method(s) of such class?

[admin]

yes and yes.

[OCAJO1]

Two last questions about 3.1:

1. Since the question asks "Add a constructor in Student class that accepts values for all of its instance fields." why not just create a
Student(Object x, Object y , Object z) constructor?

2. If instead of,

public Student() { this(0, "Dummy Name", "Dummy Address");}

I do the following,

int n = 0;
String j = "Dummy Name";
String k = "Dummy Address";

public Student() { this (n, j, k); }

the compiler complains that cannot reference n, j, or k before the super-type constructor is called, while doing the same thing within a method compiles fine:

Student method1(){
int x = 20;
String y = "Dummy1";
String z = "Dummy2";

Student s = new Student(x, y , z);

System.out.println(name);
System.out.println(s.studentId);
System.out.println(s.address);
}

I suspect compiler's complaint within the constructor has something to do with the fact that field variable initialization assignments are done at run time and constructors are called at run time, but not so with variable initializations in methods - so in the method compiler knows that value of the variables.

I think my suspicion is correct, but I can't put my finger on which is causing the real (assignments or constructor calls) complaint!

[admin]

You need to show complete code that you have doubt about. It is quite difficult understand what you are thinking with the kind of half baked statements that you have posted.

[OCAJO1]

Well question 1 was a general a question.

1. Since the question 3 in the exercises asks "Add a constructor in Student class that accepts values for all of its instance fields." why not just create a Student(Object x, Object y , Object z) constructor?

Question 2 in the pervious entry, has to do with using constants in constructor chaining call (i.e. public Student() { this(0, "Dummy Name", "Dummy Address");}) being acceptable to the compiler while using variables is not, as shown in the code below.

Code: Select all

public class Student {

public int studentId;
public static String name;
public String address;

int n = 0;
String j = "Dummy Name";
String k = "Dummy Address";

public Student (int sId, String n, String add){ 
    
        this.studentId = sId;
        name = n;
        this.address = add;
    
}

//When I use the one with constants, it compiles fine, and when I use the one with variables, causes compiler error.

public Student() { this(0, "Dummy Name", "Dummy Address");} // compiles fine 

public Student() { this (n, j, k); }  //Compiler error - cannot reference n, j, or k before the super-type constructor is called

}

The question - Is it correct to say, because field variable initialization assignments are done at run time and constructors are called at run time, the compiler does not like variables in constructor chaining?

p.s. In the pervious entry, I used the fact that the compiler does not complain when variable parameters are used in the method calls, as a means of drawing contrast between variable parameters in constructor chaining vs. method calling. But I think all it did was to confuse the question!

[admin]

1. That's a design question, way out of scope of OCAJP. It is certainly possible to create a constructor like that but it would be a horrible design. The discussion of this will take a long time and it is best you discuss this with your teacher/instructor.

2. The general idea is that constructor is meant to assign values to the fields. If you try to use the fields before they are assigned value, then the compiler will complain.
> Is it correct to say, because field variable initialization assignments are done at run time and constructors are called at run time, the compiler does not like variables in constructor chaining?
Yes. The compiler prevents you from using instance fields before they are initialized.

BTW, I have no what you are doing in the class student that you have posted. Why are you using two sets of fields??

public int studentId;
public static String name;
public String address;

int n = 0;
String j = "Dummy Name";
String k = "Dummy Address";

There is no difference between these two sets of fields. All of them are instance fields. Do you want each Student object to have these 6 fields? You should definitely discuss this face to face with a Java trainer, imho. This forum is not the right place for it.

[OCAJO1]

As for 1. that was my question. Was it a bad (horrible) design to just set all the parameters to Object and let is go.

"That's a design question, way out of scope of OCAJP. It is certainly possible to create a constructor like that but it would be a horrible design."

"The discussion of this will take a long time and it is best you discuss this with your teacher/instructor." - the sentence above was my discussion with the teacher/instructor (you get to choose whatever title you like)

As for 2. In order not to cause more confusion I figured to separate the set of fields I was using to illustrate compiler's problem with using variables in constructor chaining. I wasn't going for introducing an extra set of fields.

I believe I'm clear on both questions now.

Thanks teach