Symulator sygnalizacji świetlnej - projekt

Witam.

Chce napisać symulator sygnalizacji świetlnej i zastanawiam się jak to zaprojektować - chciałbym, aby aplikacja była jak najbardziej "poprawnie" napisana.

Pierwsza myśli to podzielić działanie sygnalizacji na kolejne fazy, zrobić jakąś pętlę inkrementującą numer aktualnej fazy a w środku w if'ach zdefiniować jakie światła mają się w danym momencie zapalić.

Coś w ten deseń (pseudo kod):

int phase = 0;

main()
{
  do
  {
  if (phase > 3)
    phase = 0;
  
  SetLightsStates(phase);
  } while (true)
}


SetLightsStates(int phase)
{
  if (phase == 0)
  {
    SetLightState(Green, On);
    SetLightState(Orange, Off);
    SetLightState(Red, Off);
  }
  else if (phase == 0)
  {
    SetLightState(Green, Off);
    SetLightState(Orange, On);
    SetLightState(Red, Off);
  }
[...]
}

Jednak wydaje mi się, że takie podejście gryzie się z zasadą open-closed, bo rozbudowa sygnalizatora o np. zieloną strzałkę będzie wymagała modyfikacji istniejących metod.

Z góry dziękuję za naprowadzenie.

U mnie na studiach robiliśmy zadania z sygnalizacją świetlną na Systemach Wbudowanych.
Wszystkie zadania rozwiązywaliśmy maszyną stanów ( https://brilliant.org/wiki/finite-state-machines/ ).

Najpierw opisujesz stany, a potem rysujesz diagram przejść.
Nie pamiętam już dokładnie jak to wyglądało na zajęciach, bo znacznie częściej robiliśmy zbiorniczki i mieszadełka, a nie sygnalizację świetlną, ale jak teraz bym to robił, to pewnie wyglądało by to tak:

while (true)
{
  switch(state)
  {
    case 0:
    // ustaw początkowe zgaszone/zaświecone światła
    // zmień stan na 1
    break;
    case 1:
    // czekaj X sekund
    // kiedy timer dojdzie do końca zmień zgaszone/zaświecone światła i zmień stan na 2
    break;
    case 2:
    // czekaj X sekund
    // kiedy timer dojdzie do końca zmień zgaszone/zaświecone światła i zmień stan na 0
    break;
  }
}

TomaszT napisał(a):

Chce napisać symulator sygnalizacji świetlnej i zastanawiam się jak to zaprojektować - chciałbym, aby aplikacja była jak najbardziej "poprawnie" napisana.

Tak jak każdy kto zaczyna nowy projekt. Ale mało kto wie jak faktycznie zacząć dobrze nowy projekt.

TomaszT napisał(a):

Pierwsza myśli to podzielić działanie sygnalizacji na kolejne fazy, zrobić jakąś pętlę inkrementującą numer aktualnej fazy a w środku w if'ach zdefiniować jakie światła mają się w danym momencie zapalić.

Nie potrzebnie myślisz o implementacji tak wcześnie.

TomaszT napisał(a):

Jednak wydaje mi się, że takie podejście gryzie się z zasadą open-closed, bo rozbudowa sygnalizatora o np. zieloną strzałkę będzie wymagała modyfikacji istniejących metod.

Nie każdy kod który nie wyczerpuje O/C jest od razu zły. O/C to jest fajna zasada jeśli jest użyta w odpowiednim miejscu - tam gdzie da się jej użyć. Wciskanie jej wszędzie w imię "poprawności" jest słabe.

To od czego powinieneś zacząć to jest zadać sobie pytanie - co ta aplikacja powinna robić? Tak, wiem, ma być symulatorem sygnalizacji świetlnej, ale po co? Tzn. co użytkownik może zrobić z tą aplikacją, jak będzie jej używał, co z niej wyciągnie. Np. "Użytkownik przy pomocy aplikacji chciałby lepiej poznać ruch drogowy" albo "Użytkownik chciałby zdiagnozować problemy z sygnalizacją", albo "Użytkownik chciałby zoptymalizować ruch na jakimś ruchliwym skrzyżowaniu". Dopiero z takich requirement'ów możesz stworzyć use-case'y (np. co w przypadku A, co w przypadku B, co w przypadku C), potem należałoby napisać testy pod to, a implementację dopiero potem. I potem powtórz - znowu zastanowić się nad tym co user chce, znowu use case, test, implementacja, etc.