• 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

Guidelines for 'extenders' of a class

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Are there any guidelines someone could give me for sub-classing a Class that I don't have the source to... an opaque class.
For example: I want to subclass the DecimalFormat Class - I dont know much about it's methods and internal workings. It has 3 const'r & about 30 methods, then it's parent class NumberFormat...
It also interacts with the classes FieldPosition, ParsPosition & StringBuffer in ways that may appear obvious - but I don't know the exact rules - and this is what wories me.
For my subclass to be well conceived and a 'good' class it needs to follow the same "rules" on the interaction (side-effects) with these classes it interacts with. Since there are no formal documented interactions between these classes - I'll be guessing - or is there a way to infer the knowledge I need?
Maybe Sun/Javadoc could come up with a way to formalize what a 'extender' of a class would need to know - just dreaming.
But are there any generalization one could make?
Thanks, David
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The interactions with a few known other classes just help illustrate how the methods are used. The real contract you must not break is the Liskov Substitution rule, that ANY class that works with the original must work with your class. If we had a full set of unit tests for the original, this would be a lot easier, but we don't, unless you want to make some
What kind of extensions do you have in mind? If it's only new methods you are probably pretty safe. If it's overriding some methods to gives different answers, you may be in big trouble.
A textbook example of potential trouble: In geometry, a square IS a rectangle. So in a drawing program you might be tempted to make Square a sublcass of Rectangle. The new rule for square is the sides are all the same length, so override setWidth() to also set height, and setHeight to also set Width. Is life good? According to Liskov, you should be able to pass a Square to the unit tests for Rectangle. How about:

And what do you do with the constructor new Rectangle( width, height )? Sometimes extending is just not the right answer.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
The interactions with a few known other classes just help illustrate how the methods are used. The real contract you must not break is the Liskov Substitution rule, that ANY class that works with the original must work with your class. If we had a full set of unit tests for the original, this would be a lot easier, but we don't, unless you want to make some


That's actually what I would do if I cared: Write JUnit tests for the base class and then see that my derived class is passing them, too!
 
David Koontz
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the input... maybe an example will help. Here the code for my extended DecimalFormat class.
The Overpunch format is used in the health care industry EDI - looks like some old cobol programmers designed the spec...
From the context of OO design - I'm thinking that it would be nice if the JavaDocs had some 'magic' way of creating a section that would lend a hand to the 'extender' of a class. It's taken me quite a while to extend DecimalFormat and I've yet to figure out if I've done a good job. Yea, one day real soon now I'm going to write those JUnit test...
 
reply
    Bookmark Topic Watch Topic
  • New Topic