c# - What Design Pattern can I use to accomplish the following -

in code able "build" object this..

// build person instance , add types person person person = new person();  person = new leader(person); person = new secretary(person); person = new parent(person); 

the goal of code above build base object has multiple types added - leader, secretary, , parent. specifically, goal able build base object (person) , make object able take on multiple types simultaneously such following condition return true:

((person leader) && (person secretary) && (person parent)) <<<-- returns true

is there design pattern can use accomplish this?

the problem above examples person object can 1 sub-type @ time , previous instantiations are, apparently, overwritten. in other words, condition return true (person parent) since last in line.

note: thought decorator pattern sounded needed, read, decorator pattern seems more adding behavior object apposed extending type.

update

for clarity - suppose should have mentioned in op trying create design classes mirrors design of rdbm.

so, continuing on original example -

my rdbm contains tables person, leader, secretary, , parent. person table has personid pk , others have personid fk.

when execute query joins tables, can determine person records have non-null fk in sub-tables.

flattened out, query result might this:

personid | firstname | leaderid | leaderapproved | secretaryid | secretaryfavpencil | parentid   ---------------------------------------------------------------------------------------------- 100      | frank     | 34       | true           | null        | null               | 700 ---------------------------------------------------------------------------------------------- 743      | dweezil   | 43       | false          | 343         | ticon              | 654 ---------------------------------------------------------------------------------------------- 567      | ahmet     | null     | null           | null        | null               | 123 ---------------------------------------------------------------------------------------------- 

the resultant table above shows frank leader , parent; dweezil leader, secretary, , parent, ahmet parent.

in data access layer, using 1 query retrieve person records along associated fk'd tables, instantiate person objects, , return list caller.

the caller can whatever needs person objects, able check types person object via (person leader).

first. classes in oop meant expressing behavior. saying " seems more adding behavior object" implies classes not behavior. if not, about?

((person leader) && (person secretary) && (person parent)) 

types in oop meant compiler. using type part of program logic considered wrong practice in oop programming. also, following code behavior. so, instead of trying mess around types, should sum requirements , figure out design, satisfy requirements. in case, first requirement ability change "role" of person @ runtime. if doesn't change behavior, simple enum enough. if there behavior, strategy, maybe combined composite possible. second requirement having behavior, executes, when person has multiple roles. if using enum, simple. becomes more complicated when use strategy. while don't have exact solution, think if going have type checking, should encapsulated inside kind of "factory" creates behavior based on person , roles.