in reply to Designing multiple related modules

5 - Have a role that all three modules do
The role says which methods have to be implemented and can contain the common behaviour. If you don't use Moose or Moo, you can still use Role::Tiny.

The Factory pattern was the first thing that came to my mind. At work, we are using it a lot (with Moose) and it makes the code much simpler and the relations between classes more explicit. In fact, the Bod::Social in example 3 already is kind of a factory class.

See also design-patterns.

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Replies are listed 'Best First'.
Re^2: Designing multiple related modules
by Bod (Parson) on May 12, 2021 at 22:29 UTC
    In fact, the Bod::Social in example 3 already is kind of a factory class

    Yes, it is of sorts.
    The first time I came across that methodology was with LWP::Authen::OAuth2 where it seems to work well. It easily allowed me to create a LWP::Authen::OAuth2::ServiceProvider for LinkedIn and allows others to create modules to connect to other social networks. The only disadvantages I see with this is that all the Service Providers get installed, even if they are not needed for the end user's application. Also, in the case of LWP::Authen::OAuth2, the author has to integrate new Service Providers into the distribution. It is quite easy to create a standalone one, as I've done with LinkedIn so I don't see that as a major problem.

[reply]

In Section Seekers of Perl Wisdom