Win a copy of Hands On Software Engineering with Python this week in the Jython/Python forum!

Charles O'Leary

Ranch Hand
+ Follow
since Jul 10, 2014
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Charles O'Leary

Firstly, I have only 15 days more for my final exam.

You will do this.  If you feel you need to for right now, you could always reschedule.  The Ocajp Wall of Fame is here to help to serve as inspiration for each of us.

Stepped onto enthuware to test my understanding, resulted in a disheartening score.

I dont know where iam weak.  

Enthuware's "Exam Objective" serves as a guide in understanding review materials.  The Sybex study guide, as well as other guides, outlines objectives for review as well, that particularly come in handy if and when we answer a question incorrectly.  

And a Warm Welcome to the Ranch!
Very inspiring!  Thank you!

... and ...

Welcome to your first Ranch posting!
Welcome to the Ranch!

From the Sybex Study Guide (I very highly recommend it, if you don't already have it.)

B. A concrete subclass must implement all inherited abstract methods.

Despite the fact that age is inaccessible by the child class, if we have an instance of a Lion object, there is still an age value that exists within the instance. The age value just cannot be directly referenced by the child class nor any instance of the class. In this manner, the Lion object is actually “bigger” than the Animal object in the sense that it includes all the properties of the Animal object (although not all of those properties may be directly accessible) along with its own set of Lion attributes.

I guess I'm trying to say that B can potentially be "interpreted" as being ruled out by some readers because the word first is (purposefully?) missing?  Indeed, Square is a (non-first) concrete subclass that must not implement all inherited abstract methods?  Square is a larger object than it's predecessors, and there really are three inherited abstract methods in Square's entire family tree?  Another alternate, "B. A concrete subclass must implement all inherited abstract methods of its direct/immediate parent class"?

Can't wait to hear your thoughts!

Hi Jeanne!

If Square extends the concrete class ChildRectangle, which extends Rectangle thus it (ChildRectangle) implements name(). Here, Square would not need to implement perimeter(), area(), nor name() because of Square's ChildRectangle and Rectangle parents.   So none of the aforementioned methods would be abstract from Square's point of view.  B would not be correct in this context?  

Do you see the point I'm trying to make?  The book's "final" answer reminds me of why (in in the book) you mentioned in practice, that you don't necessarily want to mark classes (or answers in this case?) as "final" (paraphrasing) ... you don't know all the permutations that may need to later come.

Q: Which of the following is true about a concrete subclass? (Choose all that apply)
A. A concrete subclass can be declared as abstract.
B. A concrete subclass must implement all inherited abstract methods.
C. A concrete subclass must implement all methods defined in an inherited interface.
D. A concrete subclass cannot be marked as final.
E. Abstract methods cannot be overridden by a concrete subclass.

A concrete class must implement all inherited abstract methods, so option B is correct. Option C is incorrect; a superclass may have already implemented an inherited interface, so the concrete subclass would not need to implement the method.

Why does C's (incorrect answer) provided explanation somehow not apply to B?  Asked differently, how is B correct while C is not?  Seemingly to me, both B and C potentially suffer from C's explanation?  (Although not a choice, the answer should be none of the above?)

possible answer provided per the question:

1: Interfaces are always abstract.  

Campbell Ritchie wrote: A class is an abstract datatype, but  ... The word was not used in the same context in ”abstract datatype”. Although the answer No 1 was correct, that quote didn't help to explain it.

My quote did not have any buts, exceptions, most of the times, and/or usuallys, so the word "always" was implied and was seemingly, I thought, exactly like your eloquent and concise §  The text (my quote) wriiten another way:  An interface is (always) an abstract datatype. (Period ... no buts) It defines a ...blah, blah, blah.  

So, not to beat a dead horse, but please help me to get my understanding correct on this.  I'd love to correct any misunderstanding that I may have regarding the quote that I provided.  

Campbell Ritchie wrote:

Charles O'Leary wrote:. . . Bingo! (same book)

'Fraid not. The phrase “abstract datatype” does not mean the same as “abstract class”. A class is an abstract datatype, but can usually be instantiated directly. You have found the wrong section.
If you want the definitive answer, you need to go to the Java® Language Specification (=JLS). Fortunately you don't have to go far to find the answer. Last sentence in the first paragraph, and further on in § That also tells you about the keyword abstract.

I did a "find" just to be sure.  But, please note that the word "class" was only used by you.  I think "abstract" was used in the correct context, especially as you outlined so eloquently in pointing out  §
I've enjoyed telling you that you were right all along!

Cozwaldo cozwald wrote:Thanks for the response , so just to clarify - Interfaces are always abstract , however an Interface may contain a static or default method (This method is not abstract - but as a whole the Interface is?)  

Bingo! (same book)
... And welcome to the ranch Cozwaldo.  (I think you have this one figured out.)

I feel option 1 is incorrect.

To which i then added the abstract keyword to the interface, which did not give any compile time errors.  (Which shows that interfaces are abstract - yet at the same time the only method on the interface has an impl?)

It appears that you have answered your own question?

Katherine Reut wrote:
   a) I "x"ed out the arrow pointing from a1 to "Alpha Object #1".
           *This makes the arrow from "a1.b1" to "Beta Object #1" and the arrow from "a1.b2" to "Beta Object #1" be x'ed out too!

Hi Ranchers,

Could you kindly refresh my memory on the specific rules for the above asterisk?  Or, perhaps, provide more insight?  By the way, I think this is one of the better diagrams that I've seen since it "keeps" both sets of b1&b2 within heap objects referenced by a1 and a2.  If you have a better diagram, by all means, please feel free to share it.


It should be clear that there is still a reference to the object referred to by a2, and that there is still a reference to the object referred to by a2.b2. What might be less clear is that you can still access the other Beta object through the static variable a2.b1—because it’s static.

My memory somehow wants to see a1, a1.b1, and a1.b2 as three separate (independent) references, similar to how the above answer seemingly (to me) treats a2, a2.b1, and a2.b2 as separate references?

Thanks in advance!