What you've stumbled on is the concept of public and private classes.
Public and private
classes are implemented very differently. A public class is your module's
entry point,
this is how people interact with your module. A public class is where you
define your
module's API. Private classes, on the other hand, are not meant to be
called outside your
module. Private classes are the meat of your module. This is where you will
actually
implement your module's functionality. A public class should be the only
way a user can
interact with your private classes. Public classes should generally do very
little. I
typically limit my public classes to validating the inputs received by my
parameters and
calling my private classes. Since examples speak louder than words, here's
an example:
# my_module/manifests/init.pp
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
) inherits my_module::params {
# Validate my parameters
validate_string($var1)
validate_array($var2)
validate_bool($var3)
# Call my 'private' classes
class { 'my_module::install': } ->
class {'my_module::config': } ~>
class {'my_module::service'} ->
Class['my_module']
}
The 'my_module' class is my public class. It has three parameters. All this
class does is
validate my three parameters and call my private classes. Let's take a look
at those
private classes:
# my_module/manifests/install.pp
class my_module::install (
$var1 = $my_module::var1,
$var2 = $my_module::var2,
) {
private()
# Body of the class
...
}
# my_module/manifests/config.pp
class my_module::config (
$var2 = $my_module::var2,
$var3 = $my_module::var3,
) {
private()
# Body of the class
...
}
# my_module/manifests/service.pp
class my_module::service (
$var1 = $my_module::var1,
$var2 = $my_module::var2,
$var3 = $my_module::var3,
) {
private()
# Body of the class
...
}
As you can see, I've marked my private classes with the private function.
This function
has not yet been released in stdlib, but is available in trunk
(https://github.com/puppetlabs/puppetlabs-stdlib#private). Google can show
you how
to implement this functionality in the DSL, if you prefer. The private
classes concept
allows us to make some assumptions that affect the design of this module,
specifically,
calling the variables in my_module without inheriting it first. We're
assuming that, since
this is a private class, it will not be called independently of my_module,
and those
variables will always be accessible.
This pattern can be found in a number of modules on the forge. Note, that
these modules
don't use the private function since it hasn't been released yet. They
assume that the
private classes are only being called inside their module. Here are some
examples:
https://github.com/garethr/garethr-docker
https://github.com/puppetlabs/puppetlabs-mysql
https://github.com/puppetlabs/puppetlabs-ntp
This is emerging very quickly as a good design pattern that fosters
modularity,
simplicity, good separation of concerns, and clear data flow.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/95a01d6a-f6b0-48bd-b47b-bf9ab99773e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
