Hi,
Le 22/09/2014 15:16, David Danzilio a écrit :
> What you've stumbled on is the concept of public and private classes.
Not exactly I think. The concept of public and private classes
was clear for me. It was the *implementation* of the "params"
pattern which was not clear for me, especially for private
classes. I think it's ok now. ;)
> 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.
Totally agree with that. No problem.
> 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
>
> ...
>
> }
Ok, it looks like what I gave in my previous message except:
1. the private() function. I didn't know it.
2. In my case, in a private class, I don't use parameters
and I use the variables of the public class directly with
the fully qualified name :
class my_module::service {
notify { "var1 = $::my_module::var1": }
# etc.
}
Thus, I don't have to write the parameters of the public class for *each*
private class. But, in return, I have to use the fully the qualified names
of these variables. ;)
> 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).
Thank you. Very interesting.
> 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.
Ok, thanks for your remarks.
François Lafont
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/54204073.9060906%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
