I think there are two very different kind of class files: general purpose class files like memoir and KOMA, which strive to create a uniform interface to most aspects of document formatting, and specialized class files for particular document types. Peter Wilson has already addressed the first type in his answer.
But there is another kind of class which is designed to provide predefined formatting for a particular document type. I maintain a thesis class for my university. Being an American institution, it sets out very particular and stupid formatting guidelines which all theses must follow, (in addition to specifying particular wordings in title pages etc.)
For this kind of use, a class file is quite useful. I provide a document class which people can simply "pour" their content into, knowing that the university guidelines will be met without their having to think of them. Crucially, the class does only this: it doesn't load other packages such as font packages or bibliography packages etc., or try to guess what people will need. This is where most naive class files go wrong.
Another class of this sort is beamer, which provides methods for formatting a presentation rather than a printed document. Doing this with just regular packages is really not practical.
The choice between creating a class and using a package is partially conceptual, and partially practical. Conceptually, a thesis is a different document type, and so it makes sense from the user's point of view to define it in the \documentclass command rather than in a package. As a document class it provides the all the specific boiler plate language that my university requires for the title page etc., and this is what is to be expected of a document class. The class defines various components of the document that are logically part of the document class such tables of contents formatting, special pages before appendices, formatting for landscape pages, etc.
On a practical matter, from my point of view as the author, it reduces the complexity of maintenance and documentation: I don't have to worry about people trying to use my package with some other class with which it may be incompatible, or have to maintain extra code for different document classes that are around, and I therefore don't have to document things like "must only be used with class X" etc., which I know from experience people don't tend to read.
Of course some dedicated classes are less useful. I've never been a fan of the letter class, for example, since it has various odd restrictions on the kinds of environments it allows, preferring to use article plus my own letterhead package.
So there are definitely use cases in which a dedicated class is very helpful. For most of my documents I still use the basic classes + packages, but for large documents I prefer the all-in-one classes like memoir.
Best Answer
I wrote my first LaTeX package (
idxlayout) about half a year ago (January 2010). I didn't know a comprehensive class/package writing guide then (and do not now), but I can offer a few hopefully useful hints:kvoptions.dtx-format which packs source code and documentation in one file. A good tutorial is Scott Pakins article.EDIT: One year later and with version 0.1 of my second package (
quoting) published, I want to stress some other points. Note that I'm only a LaTeX "power user" and that my recommendations probably are self-evident for programmers.As you develop your class/package, write an accompanying test document that allows for a quick overview if the (major) features (still) work as expected or if you broke something with your latest build. Whenever you stumble upon a new edge use case, amend your test document to include it.
Consider to use a version control system. I have kept copies of "major" development versions of my packages, but not used a full-fledged system like subversion, and do somehat regret it now. (I had programmed a small feature for
quoting, then dismissed it within the same "major" package version, and would now very much like to reuse the code.)