如何重构这个C＃代码？

Question

I'm working on a legacy code and I have seen a lot of code like this:

public class Person
{
    public Person(PersonData data)
    {
        this.Name = data.Name;
        this.Gender = data.Gender ;
    }

    public String Name { get; private set;}
    public String Gender { get; private set;}
}

public class PersonData
{
    public String Name;
    public String Gender;
}

public static Person ReadPerson(Reader reader)
{
    PersonData data = new PersonData;
    data.Name = reader.ReadString();
    data.Gender = reader.ReadString();

    Person p = new Person(data);
    return p;
}

The PersonData class exists for setting the private fields in Person class in its constructor. Other than that, the PersonData class introduces redundant code, as you can see now you have Name and Sex in both Person and PersonData class.

In my opion, this kind of design doesn't scale: now I have a new field "Age" to read, I have to add the "Age" property in two different places.

Is this a valid design choice (given I have see a lot code like this in the legacy code)?
How can I refactor this?

EDIT:

Those two classes are simplified version of the real code. So please forgive using string instead of enum for gender.

In the real code the PersonData have more than 10 fields so as Person class.

Answer 1

Using a parameter object is a valid approach to take when using Constructor Injection and you start getting a large number of parameters in your constructor - however it is unnecessary when there are fewer parameters like you have.

Here is a suggestion:

public class Person
{
    public Person(string name, string sex)
    {
        _name = name;
        _sex = sex;
    }

    public string Name { get {return _name; }}
    public string Sex { get {return _sex; }}

    private readonly string _name, _sex;
}

This makes the the class immutable .

Answer 2

If it would be some sort of externally facing objects (unlike data transfer objects that seem to be in your case) you can consider fluent interfaces to build them out, it not going to decrease number of classes but will let you construct object in more fancy looking way along with better control of what is required and what is optional.

See posts tagged with fluent-interface if interested. Ie Conditional Builder Method Chaining Fluent Interface :

var person = PersonBuilder
  .CreatePerson()
    .Named(reader.ReadString())
    .Sex(reader.ReadString())
    .Build()

Answer 3

One way would be instead of

public String Name { get; private set;}
public String Sex { get; private set;}

to expose a property of type PersonData

public class Person
{
    public PersonData PersonData { get; }
}

Also you can look at deriving Person from PersonData .

Answer 4

Get rid of PersonData and feed the Reader to the Constructor:

public sealed class Person
{
    public Person(Reader reader)
    {
        this.Name = reader.ReadString();
        this.Sex = reader.ReadString();
    }

    public string Name { get; private set; }

    public string Sex { get; private set; }
}

Answer 5

In general, I'd go back to the real-world (or business :)) system you are modelling. If the class matches something in that world, then it is fine. If the class is purely an artifact of the programming system and also appears unnecessary, I'd toss it. Using the "data" class can also hide various problems that using an explicit parameter would catch. For example, when you add "age" how will you detect that all cases are found? If you add it as a constructor parameter, you will get an error for every missing case.