Abu Yoosuf

It is redundant. I believe it is there for
(i) clarity
(ii) generating the 'complete' javadoc info. So a user can see the implementing interfaces as well as the parent class hierarchy.
Then again, someone may have a different reason for it.
Any way, the following example shows why it is redundant.
public class Test { public static void main(String[] args) { MyInterface b = new B(); MyInterface c = new C(); } } interface MyInterface { void get(); void set(); } abstract class A implements MyInterface { public void get() { //... } } class B extends A // implements MyInterface { public void set() { //... } } class C extends B implements MyInterface //implements clause is redundant here //we could have done without it //the compiler wouldn't have complained { }

The char assignment has "too many characters in the character literal" in the assignment, char c = '\\u0027';.
As you can't do
char c = 'ab';
it is not possible to assign
char c = '\\u0027';
The reason is, your first escape escapes the second one. What I mean is, it would have been perfectly ok if you have said,
char c = '\\';
And the resultant \ is not goin to be the escape part of the following u0027
So, you can see the rest of the characters are not valid for a char primitive type.
This escape business gave me headache for a while. Jose helped me out on one occasion. Here is the link if you're interested:
https://coderanch.com/t/240199/java-programmer-SCJP/certification/unicode-escapes
[ December 12, 2002: Message edited by: Abu Yoosuf ]

Compile time error happens when your program has one or more syntax errors.
What is syntax error? Every programming language dictates how you should write your program. If you want drive a car without getting booked in front of the watchful police officer than you don't jump the red lights. If you don't want the compiler errors than you follow the Java rules book (jls).
int a = 4, b = 5, c = 6; a = b + c; //compiler salutes you b + c = a; //compiler gives you a ticket
Runtime error occurs when you violate the rules during the execution of the program. In order to run the program, it should pass the compiler first. So, it doesn't have any syntax violatations.
public static void main (String[] args) { int i = 2, j = 100; int result = 200; for( int x = 1; x <= 10; x++ ) { i = i - 1; result = j / i; // //when x = 1, i = 1, result = 100 / 1; //when x = 2, i = 0, result = 100 / 0; //Java runtime doesn't allow you to divide an int by zero. //so it throws a runtime exception called ArithmeticException } }

My mistake too. I should have qualified my statements with a smiley or something to make it clear that I wasn't serious.
Apologies for that.
Nice talkin to you guys. Take care!

Mike,
Come on, lighten up! I was just kidding. Honestly, I am learning a lot from this site.
Anyway,
class A { //...has some characteristics //CONCRETE class } abstract class B extends A { //inherits A's characteristics //ABSTRACT class abstract void doStuff(); abstract void doSomeOtherStuff(); //... has some of my own characteristics common to my sub classes public final void commonStuffToMyChildren() { //... } } class C extends B { //CONCRETE class void doStuff() { //... } void doSomeOtherStuff() { //... } //has my own characteristics void blahblah() { //... } }
Now, if we are to provide an interface instead of the abstract middle layer class B shown in the above code snippet:
class A { //...has some characteristics //CONCRETE class } interface B { void doStuff(); void doSomeOtherStuff(); } class C extends A implements B { //... implement the methods in B }
In this approach, we have lost the common characteristic of commonStuffToMyChildren that suppose to be in the middle layer.
Another thing with this approach is, there is no stopping of jackin in the interface B to some other remotely related class hierarchy [to cut corners... believe me, in my very short life as a programmer, I have seen this happening].
Please note, I am not slating the concept of interface. All I am saying is, it has its own pitfalls.
class P { //... } class Q extends P { //... } class R extends Q implements B //from prev code snippet { // ... implements the methods for B //... really R shouldn't be implementin B }
in some other place,
B accessingR = new R();
B accessingC = new C();
IMHO, this leads to more trouble.
[ December 11, 2002: Message edited by: Michael Ernest ]

Originally posted by Michael Ernest:
Yusef really isn't defending the initial question of marking a concrete class abstract so that it can't be instantiated, a practice I still think has more potential for confusion than elegance.

Sorry Sheriff,
You're a bit late to catch up with things. We are on a detour. We are no longer heading towards the initial destination.
I was trying to answer the questions that were raised. Yes, I agree. My recent posts for this thread aren't answering the initial question.

Sheriffs,
I am currently driving a car without a Sun certified licence.
I was told that I can come to your ranch and learn to drive before taking the test. I was also told that it is perfectly legal to get into any parked car and go for test drives. If I make
mistakes along the road, there are other certified drivers and sheriffs to help me out. Here I am trying to test drive a car. You two sheriffs are pathetic. You two are taking turn to stop me every half a yard. Gosh! Now a third one joins in.
[ December 12, 2002: Message edited by: Abu Yoosuf ]

Originally posted by Mapraputa Is:
Now to add another level of hierarchy as an abstract class means to change the direction to the opposite – from concrete to more abstract. This would serve to no other goal but to introduce confusion.
Does all this make sense?

Going back to the java event api.
java.lang.Object (concrete)
|
+--java.util.EventObject (concrete)
|
+--java.awt.AWTEvent (abstract)
|
+--java.awt.event.ComponentEvent (concrete)
|
+--java.awt.event.InputEvent (abstract)
|
+--java.awt.event.KeyEvent (concrete)
The direction isn't lost.
The reason for it is, from java.lang.Object to java.awt.event.KeyEvent the relationship is a Specialization . On the other hand, from java.awt.event.KeyEvent to java.lang.Object the relationship is Generalization .
[CODE]
java.lang.Object (concrete)
^ GENERALIZATION
|
|

SPECIALIZATION
|
|
V
+--java.awt.event.KeyEvent (concrete)

Now, if you take an arbitrary relationship from this class hierarchy, say, AWTEvent to InputEvent, the direction is only one way.
[ December 11, 2002: Message edited by: Abu Yoosuf ]

We do not want the duplicate code lying around in all of your sub components. So the common stuff that require to connect to the database/rendering the output/etc.. can be pushed up the chain to MikeBaseComponent.

Ok. Let me rephrase it in "OO" terminology.
+ The Children inherit the characteristics of the Parent -i.e. Parent passes on its characteristics to the Children. Now, how do we program this concept in our chosen language?
Take your example:
abstract class Shape
{
abstract double getArea();
}
class Square
{
double getArea()
{
return ...;
}
}
class Circle
{
double getArea()
{
return ...;
}
}
class Rectangle
{
doubl getArea()
{
return ...;
}
}
and so on. For every child of Shape there will be some specific implementation of getArea().
Now, what we have here in the Parent class Shape is, a characteristic called area. Parent says to anyone who cares about it, "look, I have a characteristic called area. I know for sure my children will have this characteristic, but at this moment in time, I am not sure how that characteristic is going to be mutated by the time my child is born. So, I am going to leave it for them to sort it out."
Now, child is about to be born. It looks up and sees, hmm... Parent is saying to sort myself out. Ok. I sort myself out before I go out to the world.
This is the rationale behind the
public abstract class MikeBaseComponent{ //Every single subclass will provide its own version of the query public abstract ResultSet queryDatabase(MyParams x); }
MikeBaseComponent represents the common characteristics of its sub classes and it maintains the "IS-A" semantic with the AcmeFramework's Component class. So you can see the direction is still one way.

If all you want is to use "querying the database" functionality, there is no need to extend, you can simple call this class’ methods.

If you notice, I mentioned that this is a specific example of numerous other occurrences where abstract/concrete can be useful to the design of a solution.
IMHO, this arrangement is a benefit to the overall design of a business solution. If we can map all the business requirements to the classic Shape/Circle/Square example (OO's version helloworld example), the mega buck earners with the tag 'architects' would be queuing infront of unemployment benefit offices.
Thanks for the recommendation of Joshua's book.

With all due respect, I disagree. The essence of an "IS-A" semantic is, the characteristics of a parent are passed on to the child, i.e. super class to sub class. IMHO, the function/method calls are nothing but programmatic mapping of those characteristics of the classes.
For example, let's take the characteristic of consumption for Animals,
consume()
{
<>eat();
swallow();
<>secreteEnzyme();
<>digest();
<>excrete();
}
Now, if this is considered to be some additional functional calls that are used by consume(), and besides that they do not have any semantic, then IMHO we have misinterpreted the "IS-A" semantic. In order to say Mammal is a thing of type Animal, we need to be able encapsulate the characteristic of consumption in Animal. At the same time, Mammal should be able to expose its specific characteristic of digest() that differs from Reptile's digest().
As for the Shape example, all I know is, Yourdon brothers' are making a living out of it ;-)

Hi Mike,
I hear what you are saying. Allow me to expand on my prev example. Let's say, all of your subclasses (inherited from MikeBaseClass) rely on querying the database for exposing their respective functionality.
We do not want the duplicate code lying around in all of your sub components. So the common stuff that require to connect to the database/rendering the output/etc.. can be pushed up the chain to MikeBaseComponent.
This gives you much cleaner solution, maintaining in just one place.
public abstract class MikeBaseComponent { public void acmeFrameworkApiMethod(SomeParams x) { // do some stuff //hook into the framework to execute the query executeQuery( ... ); // do some more stuff // display the output (e.g. a web page) } //Every single subclass will provide its own //version of the query public abstract ResultSet queryDatabase(MyParams x); private void executeQuery( ... ) { //...code to access the database //polymorphic call to the specific impl of the subclasses ResultSet rs = queryDatabase(...); //... do some stuff } }
Now the sub class can provide its own impl of the query. This is probably just one instance of many number of places where this [concrete [abstract][concrete][abstract][concrete]concrete] class hierarchy can be used.
[ December 10, 2002: Message edited by: Abu Yoosuf ]
[ December 10, 2002: Message edited by: Abu Yoosuf ]
[ December 10, 2002: Message edited by: Abu Yoosuf ]

abstract class A { // 1
private abstract void m1(); // 2
private abstract class B {} // 3
private class C extends B {} // 4
}
line //2 (generates compile error):
private and abstract are mutually exclusive modifiers for methods. The private modifier indicates nobody outside of me should see it. The abstract modifier for methods indicates, someone down the line in my class hierarchy should provide the implementation.
line //3 (legal):
class A wants to have an abstract template, which it can use to define some classes. Class A decides that outside the scope of class A, the template (i.e., abstract class B) hasn't got a meaning. So, class A keeps it encapsulated within its boundary.
line //4 (legal):
You can define a private class within a class. It is perfectly legal for class C to extend from private class B as the scope of B is the entire body of class A.
[ December 08, 2002: Message edited by: Abu Yoosuf ]

Thanks.

James,
Are you disagreeing with what is in jls 3.3?
I tried few few other variations.
1. String s = "\u005c\u005a"; //doesn't compile
2. String ss = "\\u005c\u005a"; //output is \u005cZ
3. String sss = "\u005c\\u005a"; //output is \Z
I can understand the output for 2 & 3 but not for 1. If \u005c translates to \, I expected s to be assigned to "\\u005a" by the end of the translation.

JLS 3.3
The character produced by a Unicode escape does not participate in further
Unicode escapes. For example, the raw input \u005cu005a results in the six char-acters
\ u 0 0 5 a, because 005c is the Unicode value for \.

I tried to test the following code snippet, but fails with "illegal escape character".
public static void main(String[] args) { String s = "\u005cu005a"; // ^ -- error msg points //to the position marked by ^. System.out.println(s); }
What am I missing? Would appreciate any clarifications. Thanks.