What design pattern / solution helps me elegantly map classes that share the same base class

Question

I'm looking for an elegant way (a design pattern if such exists, not a library) to map two classes that share the same base class, without duplicating the code that maps the properties of the base class.

Let's say I have

public abstract class RequestBase
{
    public DateTime BornAt { get; set; }
}

public class RequestV1 : RequestBase
{
    public string Name { get; set; }
}

public class RequestV2 : RequestBase
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

and I want to

var record = this.MapFrom(someV2Request);

where

public PersonRecord MapFrom(RequestV1 request) => new PersonRecord
{
    Name = request.Name,
    BornAt = request.BornAt,
};

public PersonRecord MapFrom(RequestV2 request) => new PersonRecord
{
    Name = $"{request.FirstName} {request.LastName}",
    BornAt = request.BornAt,
};

but I don't want both methods to implement the mapping of the base class property BornAt independently.

There must be some elegant solution that I can't come up with.

Answer 1

I assume you don't want introduce a dependency from PersonRecord to the request classes or vice versa, and all the code is somewhere in your mapper class. Then the straightforward solution is

private InitCommonAttributes(PersonRecord person, RequestBase request)
{
    person.BornAt = request.BornAt;
}

public PersonRecord MapFrom(RequestV1 request)
{
    var person = new PersonRecord
    {
        Name = request.Name,
    };
    InitCommonAttributes(person,request);
    return person;
}

public PersonRecord MapFrom(RequestV2 request)
{
    var person = new PersonRecord
    {
        Name = $"{request.FirstName} {request.LastName}",
    };
    InitCommonAttributes(person,request);
    return person;
};

Extracting common code into reusable functions is not a "pattern", AFAIK.

If this is really just about one attribute and no more logic, I would consider to stay with the original solution. The extra clutter in the code above may not be worth to make this code DRY as long as the common logic here consist only in the assignment of one variable. If there is more common logic involved, however, it may be sensible.