 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2007Generics and subclassing -- best etiquette
I have come upon this several times and I am just looking for some discussion on this: given: public class MyClass extends SomeClass<String,Object> { } which is better: MyClass x = new MyClass(); SomeClass<String,Object> x = new SomeClass<String,Object>(); MyClass does nothing at all -- that wasn't a mistake above. It merely declares generic types. I like that MyClass reduces overall syntax in the code if I use it multiple times. It also hides some detailing and allows for extra functionality moving forward -- all while giving me the same typing checks. But it seems stupid to me to have a file and class that have no functional code at all. Potentially not even a constructor. Thoughts? > I have come upon this several times and I am just looking for some > discussion on this: [quoted text clipped - 19 lines] > checks. But it seems stupid to me to have a file and class that have > no functional code at all. Potentially not even a constructor. If MyClass does not anything and will not do in the future either, then I would just use generics directly. But if SomeClass is "fixed" in functionality and more functionality could be needed in the future, then a MyClass could make sense. Arne > I have come upon this several times and I am just looking for some > discussion on this: [quoted text clipped - 21 lines] > > Thoughts? It is mildly criticized at: http://forum.java.sun.com/thread.jspa?forumID=316&threadID=667720 >> I have come upon this several times and I am just looking for some >> discussion on this: [quoted text clipped - 24 lines] > It is mildly criticized at: > http://forum.java.sun.com/thread.jspa?forumID=316&threadID=667720 There are consequences to subclassing. Many times they don't signify, but you might have to cover the superclass's constructors if it has more than just a no-arg constructor, and your custom class obtains access to protected members of the superclass.  SignatureLew >public class MyClass extends SomeClass<String,Object> { } > >which is better: >MyClass x = new MyClass(); >SomeClass<String,Object> x = new SomeClass<String,Object>(); Better for what purpose? I might prefer either one depending on what I'm doing. It's a little clearer if you use a more concrete example. Contrast: Pair<Object,Long> class ResultAndTime extends Pair<Object,Long> { } as a way of storing the result of a calculation and the time it happened. For private/protected internal use when implementing something reasonably self-contained, I'm very likely to prefer Pair<Object,Long>. It's simpler, it doesn't require loading another class, and there's no danger of confusion because it's only in code that I'm working on as a unit. For a public API, or at a logical boundary inside my code, I prefer ResultAndTime. It prevents a caller from getting confused between this object and some other Pair<Object,Long>, and it gives me a place to hang useful logic (or make implementation changes) later without an API change. >But it seems stupid to me to have a file and class that have >no functional code at all. Potentially not even a constructor. Every class has a constructor. Yours has the default no-arg constructor. And a class's existence IS functional - it makes a specific type. Whether that function is sufficient to justify the cost is up to you. -- Mark Rafn dagon@dagon.net <http://www.dagon.net/> Yes, I know all classes have atleast a default constructor. That being said though -- I like the concept of a clearer line with this issue: If it's a publically exposed method then do it -- The Syntax of repeated generics is counter productive -- you could easily loose track of what's going on -- especially when you have something like List<Map<String,Map<String,Object>>> filterList(List<Map<String,Map<String,Object>>> listA,List<Map<String,Map<String,Object>>> listB) encapsulating that Generic monster would greatly simplify the syntax and specifically express what you're doing. > >public class MyClass extends SomeClass<String,Object> { } > [quoted text clipped - 26 lines] > -- > Mark Rafn da...@dagon.net <http://www.dagon.net/> > [top-posted] Please do not top-post. > Yes, I know all classes have atleast a default constructor. That being > said though -- I like the concept of a clearer line with this issue: > If it's a publically exposed method then do it -- The Syntax of > repeated generics is counter productive -- you could easily loose > track of what's going on -- especially when you have something like > List<Map<String,Map<String,Object>>> This would be a lot clearer if you'd drop a little white space into it, but then, that would diminish the point you're trying to make wouldn't it? Intellectual honesty would seem to mandate that you make the arcane idiom as readable as possible, not as obtuse as possible, before deciding if it's readable enough or not. > filterList(List<Map<String,Map<String,Object>>> > listA,List<Map<String,Map<String,Object>>> listB) > > encapsulating that Generic monster would greatly simplify the syntax Yes > and specifically express what you're doing. No - it would specifically *hide* what you're doing. This was discussed at great length recently in a thread about a proposed "typedef" feature. I myself am of the opinion that the generic decorations are useful, and that the few places where a "typedef" would help are for the most part covered by the subclassing idiom. It seems that I am in the minority in that opinion. It is difficult for me to imagine where a List < Map <String, Map <String, Object >>> would truly be useful, and if you did have something that rococo, I for one would like it explicitly documented every time, specifically so that I would *not* lose sight of how ugly and overblown the data structure is. Can you give a use case where that structure would actually be helpful, in lieu of refactoring it to something more reasonable? SignatureLew > I have come upon this several times and I am just looking for some > discussion on this: [quoted text clipped - 21 lines] > > Thoughts? This approach works if and only if everyone working on the code always uses the stub type (MyClass) instead of the real type (SomeClass<String,Object>). Since it's not obvious from looking at either the definition of SomeClass<T,U> or its docs that MyClass is the appropriate way to say "SomeClass<String,Object>" unless you documented in SomeClass yourself, it seems almost inevitable to me that if the project has more than just you working on it, or if you work on it over more than a couple of months, you'll eventually use the "wrong" type somewhere. Since MyClass adds only vacuous semantics to the program, I wouldn't do it this way. CAD 0.02, -o Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.