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 puppet-users+unsubscr...@googlegroups.com.
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.
