# Advantages of a custom class over a package and environment

What are the advantages/disadvantages of defining a class over a package and environment?

I have recently started to clean up some of the cruft in the preamble of my letters. The simplest solution might be creating a package with all my "standard" settings resulting in:

\documentclass{letter}
\usepackage{myletter}
\begin{document}%
\opening{Dear}
A letter based on the letter class and a package.
\closing{Sincerely,}
\encl{Some enclosure}
\end{letter}%
\end{document}%


But I could also making a custom letter class, which is built on the letter class, giving me:

\documentclass{myletter}
\begin{document}%
\opening{Dear}
A letter based on a custom class.
\closing{Sincerely,}
\encl{Some enclosure}
\end{letter}%
\end{document}%


Finally, it seems I could make a a package that copies a lot of the letter class and defines an environment named letter which would allow something like:

\documentclass{anyclass}
\usepackage{myletter}
\begin{document}%
\opening{Dear}
A letter based on a package that works in any class.
\closing{Sincerely,}
\encl{Some enclosure}
\end{letter}%
\end{document}%


where the package myletter could be used in any, or almost any, document class.

I don't understand what the differences are between packages and classes and when each should be used. To me it seems the first two solutions are basically identical and the code for myletter.sty would be very similar to the code for myletter.cls. In the final case, I think the code for the pacakge would need most of the code from letter.cls. The advantage of this approach would be I could include a letter in any document class. Are there other differences that I am missing?

-

The relationship between packages and classes is more conceptual than any technical difference. A class is intended to be used where design decisions are being made, usually for a specific output format. On the other hand, a package contains more programmatic code which normally will be applicable to several different situations.

In the case give, you seem to be modifying in a very specific way, tied to the idea of a letter. That suggests to me that a custom class is appropriate.

-
I wasn't sure if there was a technical difference between classes and packages (apart from the fact that a document can only use one class). This was really helpful. –  StrongBad Jan 24 '12 at 19:50

In my opinion, this depends on the purpose of myletter: If you include generally useful macros there, then I think make it a package (so that you can use it elsewhere). If you really just modify the behaviour of letter, then better make it a class.

You can of course mix the two approaches: Make a package myletter.sty with the generally useful macros. And make a class myletter.cls that firstly modifies the letter.cls class and as well automaticaly includes your package by \usepackage{myletter}. But this is probably way too complicated.

-
+1 I think this would be the cleanest solution though. –  arne Jan 24 '12 at 9:52
@arne: you mean the mixed one? –  yo' Jan 24 '12 at 10:07
I agree, never ever put some general useful macros in a class. Ok, maybe if you have so few that even a small package would be overkill. –  Martin Scharrer Jan 24 '12 at 10:08
@tohecz: Yeah, having a package with macros and a class for general layout is the best imho. –  arne Jan 24 '12 at 12:46

I don't understand what the differences are between packages and classes and when each should be used.

That's easy: There is only one class (which however, can be based on one another class (which can be also be based on one another class, etc.)), but there can be multiple packages.

If your code works well with any class it should go into a package. If it is specific to one certain class, you really should make your own class which loads the original one. This way you minimize the amount of code in the document and also the risk of usage mistakes. Like already mentioned in this thread you can split your code in specific and general macros and put the first into a class and the second one in a package. The class can load the package then, while the package can also be used with other classes.

I did this for my ydoc bundle, which provides a ydoc class but also a ydoc package which actually only loads several ydoc-* packages holding the dedicated macros. If someone wants to write a ydoc document (e.g. a package/class documentation) he/she can simply use the ydoc class. If the ydoc macros should be used with another class, the ydoc package can be loaded. If only specific features are required one or more ydoc-* packages can be loaded directly. This way you give the user a great deal of flexibility and don't limit him/her unnecessarily.

-