But there's always been a Runnable, and it's no more difficult to subclass a Runnable than a Thread. Inner classes made it easier (if more obscure) to define your subclasses, but didn't change the basic nature of the beast. (In fact, in reality inner classes don't exist.)
On Oct 22, 7:04 pm, Bob Kerns <r...@acm.org> wrote: > Because you're left with two dead birds instead of one? > > A more serious answer would be that this stems from the early days of > Java, and it was not so convenient to supply a Runnable, because there > were no inner classes back then. A lack of experience with the > language at that point left open the possibility that subclassing > Thread to get various behaviours in addition to supplying the code to > be run might be a sensible strategy. > > The documentation still offers extending thread as a co-equal option, > but offers no reason why you would do that. To more modern eyes, doing > so would be breaking down the separation of concerns. Not a serious > failing, but offering no real advantages either. > > But at the time, the culture was much more focused in class hierarchy > and inheritance. Gradually, over the years, we have learned that > delegation, proxies, and related collaboration patterns are far more > flexible and less fragile. > > On Oct 22, 2:32 pm, DanH <danhi...@ieee.org> wrote: > > > Thread implements Runnable mainly as a convenience. When you want to > > start a thread you need a Runnable to execute. You can supply a > > separate Runnable, but, since you're already creating a Thread, why > > not just make it a Runnable too, and kill two birds with one stone? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
