Why do you want classes instead of data structures? If all you want is an object with get/set methods, I don't see how that's all that different from a structure with getable/setable key-value pairs. An object would prevent the user from accidentally using some wrong name (i.e., it prevents typos), but otherwise you're just giving them a structure with more access overhead.

That said, generating a simple object from a hash is not that hard.

use strict;
use warnings;

sub hash2obj {
    my $hash_ref = shift;
    my $package  = shift;

    bless $hash_ref => $package;

    foreach my $key ( keys %{$hash_ref} ) {
        no strict 'refs';
        *{$package.'::get_'.$key} = sub { $_[0]->{$key} };
        *{$package.'::set_'.$key} = sub { $_[0]->{$key} = $_[1] };
    }

    return $hash_ref;
}

use Test::More 'tests' => 8;

my $t1 = { a => 1, b => 2 };
hash2obj( $t1, 'Test::One' );
isa_ok( $t1, 'Test::One' );
can_ok( $t1, 'set_a' );
can_ok( $t1, 'set_b' );
can_ok( $t1, 'get_a' );
can_ok( $t1, 'get_b' );
is( $t1->{a}, $t1->get_a(), 'get_a same as $t1->{a}' );
$t1->set_a(3);
is( $t1->get_a(), 3, 'a is 3 after set' );
is( $t1->{a}, $t1->get_a(), 'get_a same as $t1->{a} after set' );
[download]

This has some caveats:

• You can't give two different structures the same class name or the getter/setter subs will collide.
• This doesn't prevent the user from treating the object still as a hash and creating unsupported keys within it. If you want that, look at the privacy techniques of Object::InsideOut, or Alter::ego objects, or maybe have a look at Make an inside-out object look hash-based using overload..