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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
