• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Protected members

 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a doubt about a protected method; I began with this design:



Then I re-wrote my design to:



Is that a good design?

Thanks!


[HENRY:Enabled BB code]
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Carlos,

I'm not really sure what your question is because your examples include a lot of odd mistakes. For example, your "setId()" method in the first class returns the value of a variable, when it should return void and set the value of the variable. Also, getId and setId are both public in the first example, so I don't understand the question about being private, nor do I understand why getId() becomes protected in the second version. Doesn't make any sense, really.

But in general, it's perfectly fine for a method to call the overridden version of the same method, the way that setId() does in the second example. I should point out that the code will only compile if IllegalISBNException is a RuntimeException, as overriding methods can't introduce new checked exceptions relative to the original version of the method.
 
Ranch Hand
Posts: 257
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In the second snippet, there should be a compilation error at Line 12.

This is because setId returns String in Item and tries to return void in Book.

A method can be overridden by the changing the signature or else by redefining it.
 
Carlos Obregon
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm sorry to put code with mistakes!

My question is: I have an abstract class with a method setId() that is implement differently by its sub classes. My first thought was to make the method abstract and the attribute id private.

On the subclasses then I was trying to implement the setId() method to throw an exception based on a simple test, but because id was private (and the setId() of the super class was abstract) it was imposible to implement in that way.

The solution I used was to make the super setId() method protected (which is as close to being abstract as I can think) and make the setId() of the subclasses called it if they don't thrown an exception. Is this good design? Or how would I implement the setId() of the sub classes?

I hope I make myself understood!

Thanks.
 
Himanshu Kansal
Ranch Hand
Posts: 257
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Carlos,

I think I get what you want to do. Item is the parent with id as private and to set/get it's value you need to define methods in Item itself. Then there is not much use to making it abstract.

Carlos Obregon wrote: The solution I used was to make the super setId() method protected (which is as close to being abstract as I can think) and make the setId() of the subclasses called it if they don't thrown an exception. Is this good design? Or how would I implement the setId() of the sub classes?



"protected" and "abstract" belong to 2 different families. The former is an access modifier. If you make setId(String) abstract in Item, you cannot define it there, but you need to do that.
setId(String) can be made protected, that's ok. Don't make the Item class abstract as you aren't using it like one.

Next, as pointed earlier you can throw a checked exception, say A, in an overriding method if and only if the overridden method in parent class throws an exception, say B, which is higher in hierarchy; i.e. B is above A in the hierarchy.

Regards
 
Carlos Obregon
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your kind replies.

I will try to better explain my problem:

I have two (possibly more) classes Book and Magazine. They share some common attributes, like a String title and a String id. Obviously they will share also getters/setters for these attributes.

Books have a 13 digit ISBN id while Magazine have an 8 digit ISSN id, so they both will implement the setId(String) method differently, one will throw an exception if the parameter is not a valid ISBN and the other one will thrown an exception if the parameter is not a valid ISSN.

Both classes have a common super class Item which is abstract, because is the first non-Object class in their tree hierarchy. I must implement setId(String) so its derived classes can call super.setId(String) to change the value of the private attribute id of the item class, but making it public seem wrong as this method is not meant to be used directly, rather is meant to be overriden by the derived class (to provide a custom way to validate the id parameter)

My solution was to make the method protected, that way any derived class should be forced to override it (and given the opportunity to provide a custom check mechanism for valid id) if they want to have a public setId(String) method. I don't know if that is a good design decision and that was my question.

Thanks again.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic