You're preaching to the choir, mostly. I've been in the biz for 40 years and pretty much can program in my sleep. As you say, "do the simplest thing" is generally the best approach.
Another rule of thumb is to minimize connections (in the form of interfaces and parameters). If slicing a project in half one way results in 50 connections and another way results in 100 connections, the first option is generally the best -- inherently it's doing a better job of "decoupling" the two halves. And decoupling is very important because it makes the overall project easier to understand and easier to maintain. (I've been on giant projects that were only able to succeed because an enforced "interface" was drawn between to halves, and on other smaller projects that failed because no interfaces were drawn. But the main rule of thumb is that there are no rules of thumb -- slavishly following some "cookbook" formula for programming is a recipe for disaster. On Dec 12, 2:38 pm, Bob Kerns <r...@acm.org> wrote: > This "single responsibility" thing is often misinterpreted as "single > bit of functionality", I fear. > > It's as much about clarity of role as anything. If adding > functionality to an object blurs the lines of what that object does, > than you are undermining the abstraction. If it takes 3 pages to > describe what a module is responsible for, you have a problem. > > The flip side of "single responsibility" should always be "complete > responsibility". Failure in this is why you are dealing with 360-odd > modules. This principle argues AGAINST separating related > functionality. > > So what you have is a situation where it takes 30 pages to describe > where the responsibility for the area lies! > > Often, however, you really do want to break things up into > collaborations of smaller, more focused objects. This isn't driven > blindly by "single responsibility", but rather by looking at how you > want to allow variation -- for example, breaking out "address" from > "user", to allow multiple addresses, or alternate address validation > for different countries, etc. That might lead in turn to separating > "address" from "address validator", so you can have a single object > responsible for representing the address, and just combine it with the > appropriate validator, which is responsible only for validation. > > But note here that from the outside, you just have "user", which owns > "addresses". There is still a single cohesive outer object, which has > the ENTIRE responsibility for representing information about the user. > We don't have an interface where we supply a user, and get back an > address, and another where we supply an address and a user and get a > validator, to which we then supply an address. > > The complete responsibility for the user information is concentrated > in one place. This brings us to one of the key concepts of modularity > -- HIDING THE IMPLEMENTATION. It is this notion of "complete > responsibility" that enables modularity, by allowing details such as > address validation to become "part of the implementation" rather than > "part of the interface". > > Sometimes this approach can lead to your 360-odd classes simply being > hidden behind an interface. If so, you're still better off, because at > least you now have a cohesive interface, even if you have a complex > implementation. > > Often this situation arises from a desire to allow for future > flexibility and variation. Often, that future need for that > flexibility and variation never arises. Here, "Do The Simplest Thing > That Can Possibly Work" is your best defense. But do not follow that > rule slavishly. If your task is to create a framework on which others > will build, "possibly work" has a very different meaning than creating > a piece of end functionality. > > Still, people who have just learned to split up objects sometimes get > carried away, because they see it as a way of avoiding rewriting the > code later when things change. And often this is driven by excessive > pain in rewriting, because of bad modularity, lack of skill with > refactoring -- and lack of unit testing. > > Anyway, I just wanted to put this "single responsibility" thing in a > different light. It's really a valid idea, and not the cause of your > problem. Your problem was caused by a failure of the companion rule, > "complete responsibility". If you forget either half of this pair, > you'll create a mess. Modularity depends on both operating together. > > On Dec 11, 8:30 pm, DanH <danhi...@ieee.org> wrote: > > > 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 <jcant...@gmail.com> 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 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
