How do you model a role in object orientation?

Question

How one normally models a role (role) object-oriented?

It is by means of a composition, correct? For example, to model that a Pessoa executes the paper of a Cliente or Fornecedor, it is modeled that the Person has one Cliente, or a Fornecedor, etc..

What does that look like in UML? And in the code?

How the delegation works (Forwarding) in this story? (See example)

Edited: That’s what you get for staying in theory. It took me a while to realize that my problem is Cliente have a Pessoa and not the other way around... at least the other way around is not necessary in principle. Vide.

Answer 1

Copied from Maniero’s response, only in pseudo-Java, for better visualization (and take Boilerplate. Whoever has something to improve, just edit it).

Very simply:

public class Pessoa {
    private String nome;
}

public interface Papel {
    void umMetodo();
}

public class Cliente implements Papel {
    private Pessoa pessoa;
    private BigDecimal credito;
}

public class Faturamento {
    public void venda(Cliente cliente) {
        System.out.println(cliente.getPessoa().getNome());
    }
}

If you wish people to be aware of the roles they play, you could do it in two ways:

public class Pessoa {
    private String nome;
    private Cliente cliente;
    private Fornecedor fornecedor;
}

Each role you add needs to change the class, which violates some principles, but which is not always a problem.

Another way:

public enum TipoPapel { Cliente, Fornecedor }

public class Pessoa {
    private String Nome;
    private Map<TipoPapel, Papel> papeis = new HashMap<>();

    public void adicionaPapel(TipoPapel tipo, Papel papel) {
        papeis.put(tipo, papel);
    }
}

Instead of Enum it could use String that can facilitate or hinder, depending on the case. You could use another structure, even more specialized, in place of the map. You could have control of the papers in a separate type that abstracts the map.

Answer 2

Very simply:

class Pessoa {
    string Nome;
}
class Cliente {
    Pessoa pessoa;
    decimal credito;
}
class Faturamento {
    Venda(Cliente cliente) => Write(cliente.pessoa.Nome);
}

If you wish people to be aware of the roles they play, you could do it in two ways:

class Pessoa {
    string Nome;
    Cliente cliente;
    Fornecedor fornecedor;
}

Each role you add needs to change the class, which violates some principles, but which is not always a problem.

Another way:

enum TipoPapel { Cliente, Fornecedor }

class Pessoa {
    string Nome;
    List<(TipoPapel, IPapel)> papeis = new();
    AdicionaPapel(TipoPapel tipo, Ipapel papel) => papeis.Add((tipo, papel));
}

I put in the Github for future reference.

Instead of enum could use string that can facilitate or hinder, depending on the case. You could use a dictionary instead of the list, or another structure, even more specialized. And you could use a specific type in place of the tuple. You could have control of the roles in a separate type that abstracts the list.

UML is one of the most troll-like things I’ve ever seen, so no :)