Abstract Person with Employees and Clients I have a interface with the following implementation

public abstract class PersonInterface
{
       public abstract void Update(PersonModel person);
        public abstract void Delete(int id);


        public virtual PersonModel Find(int id)
        {
            return new List&lt;PersonModel&gt;().Find(x =&gt; x.Id == id);
        }

        public virtual IEnumerable&lt;Models.Person.Person&gt; GetAll()
        {
            return new List&lt;Models.Person.Person&gt;();
        }
}


Since the application will handle client and employee i take that class and implement it. This is because client have a diferrent way of updating its properties and the same goes from employee

public class Client : PersonInterface{
  public override void Update(PersonModel person)
        {
           // implementing the way of how the client is going to be update it

        }

        public override void Delete(int id)
        {
            // implementing the way of how the client is going to be delete it
        }
}


And employee implementation:

public class Employee: PersonInterface{
  public override void Update(PersonModel person)
        {
           // implementing the way of how the employee is going to be update it

        }

        public override void Delete(int id)
        {
            // implementing the way of how the employee ent is going to be delete it
        }
}


And my question is: is this the correct way that solve my problem when handling cases that some classes have somethings in common but there are 2 or 3 this that may vary?
Yes. When some classes have things in common but common things different having a abstract base class is a good way to go.

Having a common base class gives you a number of advantages:


Reuse between the classes. Your Find and GetAll methods don't have to be rewritten for each type of person. So you avoid having to test this N times, and you avoid accidental (and subtle) differences in implementation (=> bugs!). (N = the number of classes extending from Person)
A consistent interface. Other code using a Person doesn't (necessarily) need to know what kind of Person it's working with. For example you could write a script to get all people and update them without having to worry about the differences between clients/employees.


But you need to make sure of a few things:


The implementations in your base class must work for all children, now and in the future. So if you want to add an Employer class you don't want to have to change the base class methods. If you do so you have to test your other class implementations to make sure they still work. That being said, minor modifications often aren't too much of a big deal.
If your classes have a small amount in common but large differences you could end up only partially being able to rely on a consistent interface. So you lose the flexibility of just operating on Person objects. If your language supports it traits might be a better way to go here. Also if you find yourself in this situation your classes might be getting too big. Try breaking them down. (Nobody likes a god object!)


But broadly speaking; Yes, go for it!