• Post Reply Bookmark Topic Watch Topic
  • New Topic

anology for overridding  RSS feed

 
ankur rathi
Ranch Hand
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rules of Overridding :

1] parameter must exactly the same .
2] return tupe must match .
3] should not be more restrictive ( public -> protected : will not work ).
4] should not throw new or broader exception .

can we say it in short that overridding method should not be more smarter than original one ...

thanks .
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are you going to post every question in whatever assignement you are in this forum?

(BTW: I know you are not a native English speaker (at least I hope you are not), but "more smarter" is a grammatical nightmare. "smarter than" is how it should be written.)
 
Marcus Laubli
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rathi, that comment was off, and I object strongly. We're here to discuss programming languages, not figures.

Paul, I speak for myself, however, I'm also here to defend others in this situation. From what I gather, this is a place that should be friendly to beginners and aspiring Sun Certified Programmers. Consider me and my situation. I was bitten by a bug, suffered encephalitis (a brain infection) because of it, then found out I lost 40% of my cognitive and memory ability. Lost my job, my house, and my pride.

3 1/2 years later, I'm slowly rebuilding my life, working on these Java Certifications to prove to future employers that I am again capable of learning information, retaining it, then applying it so that I can do the kind of work I so enjoy. Programming.

Will you ask me the same question you asked Rathi? If so, I'll tell you that, until I'm asked to leave, I'll ask any Java question for as long as I like until I get a satisfactory answer.

Please be more respecting of others. We'll respect you for it.

Ernest, I see that you edited the insult out. Thank you.

Marcus
[ January 12, 2005: Message edited by: Marcus Laubli ]
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rathi -

I'm sorry that you've gotten several replies to your questions in the last two days that have not been nice. At JavaRanch, we try to encourage people to be as nice and polite as possible.

That doesn't mean, though, that people don't have the right to complain. I think Mr. Sturrock does have a point about the volume and character of the questions you've been asking. You've been making very many posts, but very few have been real questions. The one in this thread is actually one of the better ones, because at least it does have an answer (which I'll get to in a moment, below.)

Most of your posts, though -- and here I'm thinking, for example, of the series about inner classes -- are really the sort that most people answer by reading books or taking a class, rather than asking in a forum like JavaRanch. We love to help people learn here, and we also love to clarify tricky parts, and especially we love to help correct faulty assumptions. But not many people are interested in repeating entire book chapters for you. If you can't afford books -- and that's the case for some people, I understand that -- then there are a number of excellent free online books and tutorials available: just ask and we can give you some pointers.

Now, about this question: I don't think the word "smarter" captures anything for me about the relationship between a method and another method that overrides it. No, I don't think that word works. Because the rules for exceptions and for access control are different, I don't actually think there's one word that describes the relationship at all, at least not in English.

The rules are designed so that any code that can call the parent method can also call the child method. Perhaps, then, the word you want is "compatible." The child method's signature must be "compatible" with the parent's.
 
ankur rathi
Ranch Hand
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand but do you think that its all my mistake .
A person who is asking a question is definately doesn't have any knowledge about answer , it may be silly or too simple for some one who know the answer but there is point of commenting ... if you don't want to give answer its Okey ... why you are wasting the time of yours & other persons and more importantly why you are trying to stop somebody ...
Anyway , sorry for everything because I also want that it should be always a friendly place .
 
Thomas Paul
mister krabs
Ranch Hand
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Most of the rules of overriding are designed so that you can call a method using its parent class as the reference. I mean:

Parent p = new Child();
int i = p.a(); // invoke method a of child.

Let's go through the list and see what the problem would be:

1) child has different parameter list... because of overloading, Java wouldn't think you were overriding! It would think you were simply creating a new method.

2) child's return type is different. In the example above, imagine if the child returned a float. You can't load a float into an int without casting so you would crash and burn at runtime! So the return types must match.

3) Child's method is protected. In the example above, if the parent's method was public I would compile and then might fail at runtime because we don't have access to the child's protected method. Java tries to help us avoid runtime errors so this isn't allowed.

4) Child's method throws Exception while paren't method only throws IOException. We could wrap our method call with a try..catch for the IOException and the child's method could invoke an exception we aren't protecting or decalring that we throw! That would be a disaster.

So the rules are designed to protect us from runtime problems.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!