Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.swapon.de!aioe.org!.POSTED!not-for-mail
From: Sarah Connor <s.connor@gmail.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: @java.lang.DontOverride
Date: Wed, 14 May 2014 17:12:50 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 22
Message-ID: <ll086i$l8k$1@speranza.aioe.org>
References: <override-20140511031054@ram.dialup.fu-berlin.de> <lkmkeg$qko$1@dont-email.me> <1K5cv.7545$s87.2913@fx11.iad>
NNTP-Posting-Host: jLEcjRHE8BemlROrleeDmw.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/3.1 (USERIX 1.7)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.lang.java.programmer:28473

On Mon, 12 May 2014 08:25:58 -0700, Daniel Pitts wrote:

> Stefan, I think the real answer is "Don't add non-private methods to
> your JComponent extension."  Instead, create a different class that
> provides a JComponent object (perhaps a getComponent() method). All of
> the "business" logic that affects the component will live in your
> non-component class, or in the appropriate standard methods of your
> component class.

IOW, "prefer composition to inheritance".

Further to that, you might want to use a private inner class that extends 
JComponent and has direct access to the enclosing object. You'd have a 
factory method in the outer class that returns either a new instance or 
*the* instance (perhaps lazily created), depending on whether you want to 
limit to one instance.

Alternatively ... if your non-component logic has to do with some program 
state that the component displays and/or allows the user to manipulate, 
then you should probably separate it out into a model object and make the 
JComponent subclass a view object, similar to the existing ListModel and 
various list controls (JList, JComboBox, ...).