use Perl

If Abigail's technique of creating objects is "inside-out objects", then standard blessed references would be outside-in objects, yes? And I think they're OK, with a caveat.

They're very easy to use, very easy to clone, but the limitations are annoying. The lack of encapsulation is the biggest problem. However, by "lack of encapsulation" I don't mean "hide it from your users". Things works better when you provide more information, not less. Encapsulation, in this sense means stopping your objects from relying on the internals, even their own. Though I've a nasty habit of doing the following, it's a bad idea:

sub weekly_pay {
  my $self = shift;
  if ($self->{hours_worked} <= 40) {
    return $self->{wage} * $self->{hours_worked};
  }
  else {
    return $self->{wage} * 40
        + ($self->{wage} * 1.5) * ($self->{hours_worked} - 40);
  }
}

The following is much cleaner:

sub weekly_pay {
  my $self = shift;
  if ($self->hours_worked <= 40) {
    return $self->wage * $self->hours_worked;
  }
  else {
    return $self->wage * 40
        + ($self->wage * 1.5) * ($self->hours_worked - 40);
  }
}

Why? Well, some argue that it's OK for an object to rely on its own internals and some argue that the first version is slightly faster. However, there are some problems. Though some are well-known, I'll just point to the big one. What if someone wants to override wage()? They might want to look up a standard wage for temp workers, for example. Overriding that method doesn't help if the class is just grabbing the value from the hashref. The weekly_pay() method might return bad results.

The solution to that seems to be to override the weekly_pay() method. However, that means duplicating some logic and if the logic changes, that's a bad thing. Of course, with a typical blessed hashref, you still have to reach inside for the getter/setters, but that's OK. You're limiting your exposure.

Thus, encapsulation is about decoupling your code from your implementation, not about telling your users they can't see the data.