On 8/31/07, Kirk Israel <[EMAIL PROTECTED]> wrote:
>
>
> Probably the most difficult grinding of gears, then, for someone who
> gets the syntax and knows the basic concept in theory more than
> practice, is the idea that it's reasonable to make small, single uses
> class definitions (as opposed to setting properties on instances of
> classes) for the task at hand and not worry that they can't or won't
> be used elsewhere, just in the local file. On a surface level at
> least, this goes against the grain of objects as reusable components
> that should be first class objects (though obviously the trick can be
> to make the appropriate first class objects that can then be
> customized locally)
that is wrong, the defininition of the object is not that it is reusable -
it is that it encapsulates data and functions that act upon that data. the
fact that this leads to good reusability is a side effect imho.
so taking anonymous classes - no they are not reusable - but they are used
to modify the behavior of whatever it is they subclass.
inner classes are, in fact, reusable, but with a much smaller scope. they
are reusable within the top level class. this is why not all classes, even
top level, are public.
-igor
On 8/31/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > they are not "fancier" then generic data structures. they exist for a
> reason
> > and can do things other generic data structures cannot. i suggest you
> read
> > up on them, they are a pretty standard part of oop and are used
> throughout
> > java - unless of course you have been living in a struts-like land where
> oop
> > is replaced with procedural programming and you only use a small subset
> of
> > java.
> >
> > -igor
> >
> >
> > On 8/31/07, Kirk Israel <[EMAIL PROTECTED]> wrote:
> > >
> > > Well, that's a good point--
> > > They aren't complex, per se, but they (and especially anonymous inner
> > > classes) seem to show up a lot more in the class of programming of
> > > which Applets and Wicket are both subsets than they do in most of the
> > > rest of Java land. So they're a little less familiar to me, and I'm
> > > not sure if they represent more complexity (given they're obviously
> > > "fancier" than using more generic data structures in that they may be
> > > doing arbitrarily complex things in their functions) or less (since
> > > they live in the same .java file as the page, and can be nicely tuned
> > > to handle the problem at hand).
> > >
> > > On 8/30/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > > heh, if you think inner classes are complex you are def using the
> wrong
> > > > framework
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 8/30/07, Kirk Israel <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Ok, thanks...
> > > > > I refactored what i had with this in mind. It was a little more
> > > > > complicated because I want to delegate responsibility for
> generating
> > > > > the link and caption to the page (some of our links our kind of
> > > > > complex to promote lazy initialization), so the page is still
> calling
> > > > > into static functions to know what id to give the caption and
> label.
> > > > > Plus I had to create an additional class to hold that link plus
> the
> > > > > seperator( to do the comma and "or" in something like "A, B or C")
> > > > >
> > > > > The list is then
> > > > >
> > > > > add(new ListView("linklist", listSepLinks)
> > > > > {
> > > > > private static final long serialVersionUID = 0L;
> > > > > public void populateItem(final ListItem listItem)
> > > > > {
> > > > > CaptionedLinkAndSeperator linkAndSep =
> > > > > (CaptionedLinkAndSeperator)listItem.getModelObject();
> > > > > listItem.add(linkAndSep.getPageLink());
> > > > > listItem.add(new Label("sep",
> > > > > linkAndSep.getSeperator()));
> > > > > }
> > > > > });
> > > > >
> > > > > and the HTML is then
> > > > >
> > > > > <span wicket:id="linklist">
> > > > > <a href="#" wicket:id="link" class="link"><span
> > > > > wicket:id="caption">[LINK CAPTION]</span></a><span wicket:id =
> > > > > "sep">[,]</span>
> > > > > </span>
> > > > >
> > > > > So, the complexity isn't too bad despite the inner class and it's
> less
> > > > > kludgey than what i had earlier.
> > > > >
> > > > > Thanks.
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
