I can tell you I've done this 8 different ways. In general, my rule of thumb is to make things as small as is possible and still be useful. This applies to methods, to classes, to applications. Make a method that does one thing, and only one thing. Make a class that does one thing, and only one thing. Then write controller classes that stitch this stuff together. It's hard, but it ultimately pays off because so much of it is reusable and easy to maintain. If you have a class that only does one thing, and it has a bug - i.e. in some state it WON'T do that one thing - it's much easier to fix than a class with 100 methods. Unraveling that kind of thing is nearly impossible. Having 25 classes, each with 5 methods and 2 callback events, is challenging to maintain, too, but the difference is you can look at any one of them and understand its purpose, it's contract with the things that make use of it, and you can fix it (and so can anyone else).
As for all your callbacks, they don't bother me. The trick is to be clear and deliberative in the places you add them and how they work. Try and make things consistent without confusing. For instance, I have a class that manages a lot of server communication. Urls get passed around a lot. I could make the argument for fetching a url just be "url" and the callback, which includes the url which it is calling back for, could also have a "url" value. And I could store the current url as "this.url". But then you start getting confused as to which url you are working with. Thus, I name them requestUrl, responseUrl, and currentUrl. Things like this feel consistent and aren't confusing. As for automating a lot of this stuff, that's where abstractions pay off. Writing a class that is abstract and does one small thing comes in handy in all sorts of places you may not have planned on. It's also important to document what you're writing, which is a task that is all too often forgotten about until the last minute. Inline comments about what this thing does are enough to help you keep it straight. On Wed, Nov 4, 2009 at 1:09 PM, Ryan Florence <rpflore...@gmail.com> wrote: > > Most public facing websites I do are pretty basic, with a handful of > unrelated classes instantiated (a gallery, some menu navigation, maybe some > ajax fun). You know, a fancy "brochure" website. > > But when developing web applications I've ended up either created a > do-everything-class that has tens if not hundreds of methods; or splitting > up each piece of the page into separate classes with a lot of events used to > communicate with each other. > > The do-everything-class just feels wrong. > > 10-20 classes on a page with all sorts of `onWhatever` functions makes a > mess out of my domready code. > > Is there a happy medium? Like a "controller" class? > > So I'd instantiate all the classes, and then pass them in to the controller > class and from there define how and when they communicate with each other? > > Simple Example to better illustrate the concept: > > A photo gallery has > 1) a carousel full of thumbnails with next and previous buttons > 2) and an image viewer that loads an image, zooms in and zooms out. > > When a thumbnail is clicked, the image viewer should load the image. > > In the end will be some theoretical methods: > - loadImage > - next > - previous > - zoomIn > - zoomOut > > I could either > 1) create a single class that does everything or > 2) have a class for the image viewer with loadImage, zoomIn, and zoomOut, > and then a carousel class with an onSelect event, used to send a message to > the viewer class to load the correct image. > > I'm currently doing number 2 on a project but all the onWhatevers are > starting to drive me nuts and I'm tempted to go back to a do-everything > class. But I just thought about creating a class to handle all the > communication between my classes. So I could just pass in the two class > instances (carousel and image viewer) to the controller class and then > define inside there what to do onSelect of a thumbnail. > > Is that making sense? Again, the photo viewer is a simple example to > illustrate a problem. I don't need any links to good photo viewers. Any > tips, articles, thoughts? > > Ryan Florence > > [Writing TextMate Snippets] ( http://blog.flobro.com/ ) > >
