Generally, an object can be assigned with a role by means of class inheritance or interface implementation.
I just wanted to point out that using this design is more limited than another design, where you actually instantiate the role types that you define separately from the actors that play them.
If you declare that "Seller extends Person", that is to say that Sellers can only be Persons -- nothing else in your system can act as a Seller, but it is feasable that a Company could also act as a Seller, which wouldn't be possible in a single-inheritance language.
Another frequently used design is "Person implements Seller"; this is a little more flexible, because now Company can also implement Seller. However, this design dictates that **every** Person and **every** Company is a Seller. Perhaps this shouldn't be possible, for example, if a Person or Company has to go through some sort of approval workflow before being allowed to be a Seller in the system.
A design that allows for more flexibility is to define Person, Company, and Seller (and Buyer) separately as independent classes, with the Seller-specific behavior in the Seller class. Then, create Person and Company instances to your heart's content in the system, but none of them need be Sellers or Buyers right off the bat. Later (or at the same time, depending on your needs), you can associate a distinct Seller instance with a Person, and another distinct Seller instance with a Company. The association is the manifestation of the participation of the actor (Person, Company) in the system as the associated role (Seller, Buyer). It is actually a compositional relationship between actor and role, in general, where the actor composites the role.
This is a key difference that has many benefits, as it allows one to differentiate instances of Person, Company, Buyer and Seller.
Google "Streamlined Object Modeling" for more information on a full treatise of this design. Also, check out "Domain Driven Design" as well.