I want to ask you for your opinion to the following general problem:
- As anybody would agree with: global variables are bad.
- That means: Feed as much information to a function as you need to do the job.
That also is a building block to make the function well testable.
- In a program which needs a database more or less all over the codebase
you have to have a database handle.
- Asuming the above statements are right you would have to provide
the database handle to a function which needs that database handle.
That's not too bad at the moment.
Now you're using the several functions
Function a uses b and b has to use c. That means you have to insert dbhandle in the function signature of b even if b doesn't need it by itself.sub a { my ($dbhandle) = @_; ##does soemthing with dbhandle } sub b { ##doesn't need dbhandle } sub c { my ($dbhandle) = @_; ##does soemthing with dbhandle }
So, as more or less the whole application needs the database it happens that more or less all functions need a dbhandle. That means that the signature of more or less any function does have the dbhandle parameter.
Is this the right way to do this? Or would it be better to implement the functions the way that they can "grab" the dbhandle from somewhere (singleton = global variable)? When you add other things to the example above, e.g. a logging object, than the function signatures are growing with elements which you can find in more or less any function. (Logging is IMHO a much better example of an item you need everywhere, but logging is not a requirement to solve the initial business requirement. Log::Log4perl solves this elegantly by providing a singleton. So you can add logging whereever you want simply by calling get_logger).
Advices and ideas welcome.
Best regardsIn reply to Global or not global by McA
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |