Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: How to extend an array Date: Tue, 31 May 2016 14:11:22 -0400 Organization: A noiseless patient Spider Lines: 46 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 31 May 2016 18:11:25 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="2d081e2f7155c28005d4472f67c2f43d"; logging-data="11011"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Z8jfuSVmFNMsGsPucyB6u" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 In-Reply-To: Cancel-Lock: sha1:FknD3UbgnoULLXb1AabHvCV876c= Xref: csiph.com comp.lang.java.programmer:34429 On 5/31/2016 12:09 PM, Eric Douglas wrote: > On Tuesday, May 31, 2016 at 11:53:00 AM UTC-4, Eric Sosman wrote: >> I don't see why Class2 needs its own list of listeners, nor its >> addExtendedListener() method. Since Listener2 extends Listener1, a >> Listener2 "is a" Listener1 and can be handled just fine by Class1's >> addListener() method. Unless there's some additional concern that >> you've simplified away, I think you're working too hard. >> >> Side-issue: Since Class1 and Class2 extend JFrame, they are both >> Swing components. Swing components are not thread-safe (by and large), >> so it's not safe to manipulate them from more than one thread. That >> thread should be the Event Dispatch Thread or EDT. Your code, though, >> does a *lot* of manipulation of these Swing components on a non-EDT >> thread: It constructs them, resizes their windows, and makes them >> visible, all from the startup thread that calls main(). Don't Do That. >> (To be fair to you, Sun themselves didn't at first realize this was a >> no-no, and some of the early Swing examples commit this same error. >> Pay attention to more up-to-date examples, that's all I can suggest.) > > As I mentioned this is a simple sample to show the structure, so yes those are non issues. You see Listener2 has additional methods. Class2 in the sample didn't call the method(s) but will need to. Test programs instantiating a Class1 will need to handle all Listener1 methods. Test programs instantiating a Class2 will need to handle all Listener1 methods plus the additional methods in Listener2. The second issue, yes, Eclipse runs this sample as is and I left it out but I do normally instantiate the Swing GUI objects (JFrame, or JDialog) from an EventQueue.invokeLater(). It doesn't matter that Listener2 has additional methods beyond those of its base interface Listener1: Any class that implements Listener2 perforce implements Listener1, so a Listener2 implementation "is a" Listener1 implementation, and can be handed to Class1's addListener(). In fact, in your sketch you do exactly this: Class2 hands the Listener2 it is given to its Class1 superclass, which accepts it because ... it "is a" Listener1. As for users of Class2 being required to handle the additional methods of Listener2 -- well, I'm afraid I don't see the need. Since a Class2 "is a" Class1, a user of Class2 instances should be able to treat them as Class1 instances (because they "are"), and should thus be able to deal with Listener1 events alone. If for some reason this is not possible, I think there's something highly suspect about your design: It's like "MyList extends AbstractList, but you can't treat it like a List." Perhaps a less "simplified" example would help ... > The question here is about the array. Does this make sense, having a class extending a class overriding a method that accepts an object for an array with a class which extends that object's class, just using an array of the same name and having to add it to that array plus the super...? Since I'm still not sure I understand what you're trying to do, I can't comment. Not usefully, anyhow. -- esosman@comcast-dot-net.invalid "Don't be afraid of work. Make work afraid of you." -- TLM