To avoid heavy network traffic, user data is cached locally for a time, so when $user->info is requested, the user code first tries Lookup::Local to determine if information is cached locally, and if not then uses Lookup::Remote (I realise these are less than perfect names, but they suffice).

It's actually not separated out like that (there is just one Lookup class to perform the actual information collection), but for the purposes of discussion it might help to know that there are potentially two steps to determine user information.

The $RemoteURI doesn't relate at all to the User, it is just where information will be pulled from - it's configurable, because one installation of the code may be configured to query server A, while another is configured for server B; and it's a class variable because all instances of the class have to hit the same server, and it seems wasteful to store this per-instance. The nature of this product means that round-robin DNS or other centralised user management is not an option.

Some very simplified sample code is shown below, with questionable bits commented.

use User;

my $config = AppConfig->new;
$config->define(
  remote_uri => { DEFAULT => '', ARGCOUNT => ARGCOUNT_ONE }
);
# config file sets remote_uri;
$config->file('/path/to/conf');

### I'm trying to avoid having to do this.
use Lookup::Remote;
Lookup::Remote->remote_uri($config->remote_uri);
#######

# Set user data from cache or remote as available.
my $user = User->new(id => '1234')->init(); 

# Do stuff with $user..
[download]

It sounds as if the real issue has to do with the main app. Are you desiging both a front-end and an initial startup in the same file? That may be where the confusion comes in.

This is very similar to what web application servers must doing during startup on a database, for instance, passing in a password for initial database startup. An application initialization script reads the config files and passes information to appropriate objects, which (usually) create and maintain pools of themselves, passing them to requesting objects. Avalon (in Java) has this kind of approach, and it's a good separation of concerns. Your front end app would simply request a User from a Factory, how it got populated (as you said), is none of it's concern.