Class design with SOLID Principle using C#

Question

Each elevator has a set of states.

• Maintenance: the elevator does not react to external signals (only to its own signals).

• Stand: the elevator is fixed on a floor. If it receives a call. And the elevator is on that floor, the doors open. If it is on another floor, it moves in that direction.

• Up: the elevator moves up. Each time it reaches a floor, it checks if it needs to stop. If so it stops and opens the doors. It waits for a certain amount of time and closes the door (unless someting is moving through them. Then it removes the floor from the request list and checks if there is another request. If so the elevator starts moving again. If not it enters the state stand.

• Down: like up but in reverse direction

NOTE: Some elevators don't start at bottom/first_floor esp. in case of sky scrappers. min_floor & max_floor are two additional attributes for Elevator.

My demo design:

public abstract class Elevator
{
    protected bool[] floorReady;
    protected int CurrentFloor = 1; 
    protected int topfloor; 
    protected ElevatorStatus Status = ElevatorStatus.STOPPED; //ElevatorStatus is enum

    protected virtual void Stop(int floor){}
    protected virtual void Descend(int floor)  {}
    protected virtual void Ascend(int floor) {}
    protected virtual void StayPut () {}
    protected virtual void FloorPress (int floor){}

}

interface ILogger
{
    void RegisterLog(string Message)
}

public FileLogger : ILogger
{
    void RegisterLog(string Message)
    {
        //Custom Code
    }
}
public class MyElevator : Elevator
{
    // All method overrride for base
}

//Client class
class program
{
    public static void main()
    {
     //DI for calling Looging

    }
}

Can somebody help me to design my classes which satisfy all the SOLID principle..

Thanks in advance...I want to design a Elevator Simulator using SOLID principles.

Answer 1

Look at the state pattern.

By using it you move the business rules for moving the elevator to each specific state. So instead of using an Enum you let each state determine what to do next (like which state to use for the next action).

It also allows you to add new functionality (by adding more states) without modifying the elevator class (which is important from the SOLID perspective).