我可以使用什么设计模式来完成以下操作

Question

In my code I would like to be able to "build" an object like this..

// Build a Person instance and add types that the person is
Person person = new Person(); 
person = new Leader(person);
person = new Secretary(person);
person = new Parent(person);

The goal of the code above is to build a base object that has multiple types added to it - a Leader, a Secretary, and a Parent. Specifically, my goal is to be able to build a base object (Person) and make that object be able to take on multiple types simultaneously such that the following condition would return true:

((person is Leader) && (person is Secretary) && (person is Parent)) <<<-- Returns True

Is there a Design Pattern that I can use to accomplish this?

The problem with the above examples is that the person object can only be one sub-type at a time and all previous instantiations are, apparently, overwritten. In other words, the only condition that would return true is (person is Parent) since it is the last in line.

Note: I initially thought the Decorator Pattern sounded like what I needed, but from what I read, the Decorator Pattern seems to be more about adding behavior to an object as apposed to extending its type.

Update

For clarity - I suppose I should have mentioned in my OP that I am trying to create a design with my classes that mirrors the design of my RDBM.

So, continuing on with the original example -

My RDBM contains the tables Person, Leader, Secretary, and Parent. The Person table has the PersonId PK and the others have a PersonId FK .

When I execute a query that joins all the tables, I can determine which Person records have a non-null FK in the sub-tables.

Flattened out, a query result might look like 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 us that Frank is a Leader and a Parent; Dweezil is a Leader, a Secretary, and a Parent, an Ahmet is just a Parent.

In my Data Access Layer, I am using one query to retrieve all the Person records along with their associated FK'd tables, instantiate Person objects, and then return a List to the caller.

The caller can then do whatever it is he needs to do with the Person objects, but he is able to check all the types that a Person object is via (person is Leader) .

Answer 1

I think the Strategy pattern should fit your needs.
Your question does not specify all of your requirements, but you can have an object that is a composite of types such as Secretary Leader and Parent , then at run time you will have to choose which one of them is the chosen strategy at the moment.

Also, assuming all of the types have some kind of a common interface which the composed object will implement as well you can keep the instances in an array, something like:

IPerson[] _rolles  = 
                 new IPerson[]{new Leader(this), new Secretary(this), new Parent(this)};

And have a method for type checking which will look something like this:

        public bool Is(Type type)
        {
            return this.Is(new Type[]{type});
        }

        public bool Is(Type[] types)
        {
            bool isType = true;
            foreach (var type in types)
            {
                isType &= this._rolles.Any(r => r.GetType() == type);
            }
            return isType;
        }

---

Edit:

A fuller code example:

    public class Person : IPerson
    {

        List<IPerson> _rolles;
        IPerson _chosenStrategy;


        public Person()
        {
            this._rolles =
                new List<IPerson>() { new Leader(this), new Secretary(this), new Parent(this) };
            this._chosenStrategy = this._rolles[0];
        }

        public void AddRole(Func<Person, IPerson> creator) {
              IPerson newRole = creator(this)
              //You can choose to remove duplicate roles by uncommenting the following line:
              //this.RemoveRole(newRole.GetType());
              this._rolles.Add(newRole);
        }

        public void RemoveRole(Type type) {
              this._rolles.RemoveAll(r => r.GetType() == type);
        }


         public bool Is(Type type)
        {
            return this.Is(new Type[]{type});
        }

        public bool Is(Type[] types)
        {
            bool isType = true;
            foreach (var type in types)
            {
                isType &= this._rolles.Any(r => r.GetType() == type);
            }
            return isType;
        }

        private void SetStrategy(Type type)
        {
            this._chosenStrategy = this._rolles.Where(r => r.GetType() == type).FirstOrDefault();
        }

        /*Rest of Implementation goes here*/
    }

And the other required classes:

    interface IPerson
    {
        /*Implementation goes here*/
    }
    class Leader : IPerson
    {
        public Leader(IPerson p)
        {

        }
        /*Rest of Implementation goes here*/
    }

    class Parent : IPerson
    {
        public Parent(IPerson p)
        {

        }
    }

    class Secretary : IPerson
    {
        public Secretary(IPerson p)
        {

        }
        /*Rest of Implementation goes here*/
    }

Answer 2

((person is Leader) && (person is Secretary) && (person is Parent)) <<<-- Returns True

Technically this is possible, but only if a Leader is one of the other two, and one of the other two is always one of the others.

public Leader : Person { }
public Secretary : Leader { }
public Parent : Secretary/Leader { }

If this isn't always the case, then your specific request is impossible using that specific code.

If you're dead set in using is , then alternatively, you could use interfaces:

((person is ILeader) && (person is ISecretary) && (person is IParent)) <<<-- Returns True

public inteface IPerson;
public inteface ILeader : IPerson;
public interface ISecretary : IPerson;
public interface IParent : IPerson;

public Leader : ILeader;
public Secretary : ISecretary;
public Parent : IParent;

public LeaderSecretary : ILeader, ISecretary;
public LeaderParent : ILeader, IParent;
public SecretaryParent: ISecretary, IParent,
public LeaderSecretaryParent: ILeader, ISecretary, IParent;

But seriously do not do this.

Answer 3

First. Classes in OOP are primarily meant as expressing behavior. You saying " seems to be more about adding behavior to an object" implies that your classes are not about behavior. If they are not, then what are they about?

((person is Leader) && (person is Secretary) && (person is Parent))

Types in OOP are meant for compiler. Using type as part of program logic is considered wrong practice in OOP programming. Also, following this code is clearly a behavior. So, instead of trying to mess around with types, you should sum up your requirements and figure out a design, that does satisfy your requirements. In your case, first requirement is ability to change "role" of a person at runtime. If this doesn't change the behavior, simple Enum is enough. If there is behavior, then Strategy , maybe combined with Composite is possible. Second requirement is having behavior, that only executes, when person has multiple roles. If you are using enum, then it is simple. But it becomes more complicated when you use strategy. While I don't have exact solution, I think if you are going to have type checking, then it should be encapsulated inside some kind of "factory" that creates the behavior based on person and his roles.

Answer 4

我认为你需要的是装饰模式，你可以使用工厂和策略来帮助你... 希望这可以给你一个想法