Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Generics Date: Wed, 17 Aug 2016 20:06:57 -0400 Organization: A noiseless patient Spider Lines: 54 Message-ID: References: <681a67de-8a78-46ab-a028-5176a48df402@googlegroups.com> <2ce12c5a-fdb0-43ad-b4a3-4ffc28836df3@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 18 Aug 2016 00:07:11 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="22e5ab429c5a4bb738666b9c52e40d69"; logging-data="22037"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+rYolWYDb23260kxaHI+BM" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <2ce12c5a-fdb0-43ad-b4a3-4ffc28836df3@googlegroups.com> Cancel-Lock: sha1:lRI2As8Jwmne8EyuJYyjcLw1edw= Xref: csiph.com comp.lang.java.programmer:35387 On 8/17/2016 5:03 PM, Eric Douglas wrote: > On Wednesday, August 17, 2016 at 3:22:32 PM UTC-4, Eric Sosman wrote: >> However, I'd view this need with suspicion. The "instanceof" operator >> (and its reflective counterparts) are often signs that the design >> should be reconsidered -- and perhaps retained, but only after due >> thought has lowered the raised eyebrows. More commonly, it's a sign >> that polymorphism is not being used to best advantage. > > This seemed like a separate topic for a new thread but in this case is related to the XML. Okay. Disclaimer: I'm not an expert on XML, and even less of an expert on frameworks-that-semiautomatically-XMLize-Java-classes, so much of what follows may be worth less than you're paying for it ... > As the design states, TestA is just a wrapper class. It holds a variable that is a List which may contain anything which extends TestB which may be TestC, or TestD, etc. Back on familiar ground, I must ask: Do you really need a List, or would a List be just as good (possibly better)? There *is* a difference, but I'm not sure you've made a case one way or the other. > I want each instance of TestA to be able to marshal itself which requires knowing the specific classes of TestC, etc. This strikes me as bass-ackwards design: You're asking the container class TestA to have special knowledge of every possible contained class TestC, TestD, TestUnanticipated, TestUnheardOf, TestOsterone, ... Does that strike you as a good idea? Thought experiment: Should Object's toString() method have special knowledge of all subclasses of Object, so that it can know how to render them all? So, you've introduced the abstract class TestB to be the superclass of all the possible contained classes; that's fine. Why shouldn't TestB have a (probably abstract) method to do the required marshalling, so TestA (the container; damn, I wish you'd used descriptive names!) can call it on each contained object instance? > but I want to hide the marshalling so the instance of TestA only has to tell it that class name once. ... whereas a more "traditional" design -- each class is responsible for its own marshalling -- would require telling TestA the class name, er, zero times. *And* would allow for future introduction of TestImony without modifying TestA. > So I'm using a method to pass in the class name because TestA is the root object for this XML so adding a parameter to the constructor gets ugly.. ... and I'm out of my comfort zone again, not being familiar with the oddities of these various auto-XMLization frameworks. Perhaps they really *do* require bass-ackwards object-disoriented design, but if so I'd have to question their worth. As I said, possibly worth less than you paid ... -- esosman@comcast-dot-net.invalid The Tooth Fairy has gone high-tech, now pays in Bitecoin.