I'm working on (repairing) an application right now where the original developers apparently believed in that "single responsibility" thing. 127K lines in 360-odd modules, when the job could easily have been done in 35K. (We know this because the same function was implemented on another platform in that much code.) Each class/module only does "one thing", but the code is virtually impenetrable, nasty to maintain, and prone to serious performance problems.
Good design generally dictates that a given class should ABSTRACT a particular resource or function. That is to say, the class should present a virtual, idealized representation of the resource or function that permits the user to use it without concern for the "dirty" details inside, and without having to know the protocols, timings, etc, that may be involved. This often means that the class must do many different things, when you look inside. But on the outside it's a consistent, homogeneous interface. On Dec 9, 5:43 pm, jim <[email protected]> wrote: > In a shared project, we have an Adapter class (extends BaseAdapter, > implements ListAdapter). In its constructor, this class fetches an RSS > feed from the internet and parses the returned XML document to obtain > the data it will 'adapt'; the data is kept in a private class > variable. > > This is seen as the "Android way" of doing things by the author and is > supported by the project lead. > Can this be considered a "Best Practice"? > Can it be justified on the grounds that it (may?) increase > performance? > Doesn't it violate the general Object Oriented Design (OOD) principle > that a class should have only a "Single Responsiblity"? > Are best practices for OOD or Java to be set aside in Android > development? -- 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
