Untested code:

# User doesn't mind if it is local or remote, he wants the data
package Lookup;
...
sub is_user_in_cache { ... }
sub get_user_data { warn 'You should implement this method!'; }
...
package Lookup::Remote;
use base 'Lookup';
sub get_user_data { ... }
...
package main;
use Lookup::Remote;
my $lookup = Lookup->new({ remote_uri => $uri, });

use User;
# Tell User class the lookup method it will use.
User->set_lookup($lookup);
my $user = User->new({ id => 1234, });
[download]

I hope this helps.

Your answer mentions exactly what I'm trying to avoid - that the user of User knows about User's implementation:

#  izut said
use Lookup::Remote;
my $lookup = Lookup->new({ remote_uri => $uri, });
[download]

This to me looks like User's use of Lookup::Remote is not hidden, and thus breaks the interface between User and code using it. In other words, any code instantiating a User does not and should not need to know that there could be a vast amount of code tucked away providing the user information (or the ultimate source of that information); merely that when $user->info() is requested, it is available.

--
Now hiring in Atlanta. /msg moot for details.

package LookupFactory;

use base qw( UserSource );

sub init_lookup {
  # run config based upon type of source requested
}

package UserSource;

sub get {
  # get the type of user source (lookup, database, whatever)
}

package User

sub new {
  # get a source based upon whatever the User config says to get
}

package App

$user = User->new();

$user->info() # look ma!  no config!
[download]

I don't think it would break your model to have the user request the type of source from a config file. It's actually still not even necessary to do that, as it could select from a pre-created list of Lookup Sources.

Code is (hopefully obviously) not tested and not intended to work

You have to specify where the User module will load its data. You can also use something like this:

package Lookup;
sub new { # gets some config file };
sub get { warn 'You should implement this method!'; }
sub set { warn 'You should implement this method!'; }

package Lookup::Remote;
use base 'Lookup';
sub get { ... };
sub set { ... };

package main;

use User;
User->init({ source => 'Lookup::Remote', });
my $user = User->new({ id => 1234, });
[download]

Or you can even tell User constructor to check some value in main scope:

package User;

sub new {
    ...
    $self->{'source'} = $main::USER_LOOKUP_SOURCE;
    ...
}

package main;
use User;

our $USER_LOOKUP_SOURCE = LookupFactory->new('Remote');

my $user = User->new({ id => 1234, });
[download]

You still have to inform the User class what class it will use to get data. I can be wrong, that's the reason I come to perlmonks :)

Update: I think it is like DBI specs. I don't know what is going under the DBD module, but I have to inform DBI where the data is.

The $RemoteURI parameter tells Lookup::Remote which URI to request user information from, given a user-id. It performs this request via LWP. The User class encapsulates information concerning a user (surprise!).

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]

--
Now hiring in Atlanta. /msg moot for details.

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.