The caveats of parameterized classes

The consequence of allowing class parameters is almost obvious: you lose the singleton characteristic. Well, that's not entirely true either, but your freedom in declaring the class gets limited drastically.

Classes that define default values for all parameters can still be declared with the include statement. This can still be done an arbitrary number of times in the same manifest.

However, the resource-like declaration of class { 'name': } cannot appear more than once for any given class in the same manifest. This is in keeping with the rules for resources and should not be very surprising—after all, it would be very awkward to try and bind different values to a class's parameters in different locations throughout the manifest.

Things become very confusing when mixing include with the alternative syntax though. It is valid to include a class an arbitrary number of times after it has been declared using the resource-like notation. However, you cannot use the resource style declaration after a class has been declared using include. That's because the parameters are then determined to assume their default values, and a class { 'name': } declaration clashes with that.

In a nutshell, the following code works:

class { 'apache::config': }
include apache::config

However, the following code does not work:

include apache::config
class { 'apache::config': }

As a consequence, you effectively cannot add parameters to component classes, because the include statement is no longer safe to use in large quantities. Therefore, parameters are essentially only useful for comprehensive classes, which usually don't get included from different parts of the manifest.

Preferring the include keyword

Ever since class parameters have been available, some Puppet users have felt compelled to write (example) code that would make it a point to forgo the include keyword in favor of resource-like class declarations, such as this:

class apache {
  class { 'apache::service': }
  class { 'apache::package': }
  class { 'apache::config': }
}

Doing this is a very bad idea. We cannot stress this enough: one of the most powerful concepts about Puppet's classes is their singleton aspect—the ability to include a class in a manifest arbitrarily and without worrying about clashes with other code. The mentioned declaration syntax deprives you of this power, even when the classes in question don't support parameters.

The safest route is to use include whenever possible, and to avoid the alternate syntax whenever you can. In fact, Chapter 8, Separating Data from Code Using Hiera, introduces the ability to use class parameters without the resource-like class declaration. This way, you can rely solely on include, even when parameters are in play. These are the safest recommended practices to keep you out of trouble from incompatible class declarations.