# Proiect POO - Sistem Energetic

Nume: Radu-Stefan Minea
Serie: CA
Grupa: 324CA
Timp petrecut pe tema: 5 zile (etapa 1) + o zi (etapa 2)

Link repo: https://github.com/raduqq/POO-Projekt

===============================================================================
## Relatiile intre clase

* Player (Abstract Class) -> Consumer, Distributor

    - Consumer: agrega un Contract si un Distributor. De ce?
        > Atunci cand efectueaza plati, sa nu mai fie nevoie sa-si caute
        Distributorul in baza de date
        > Atunci cand nu poate plati intr-o luna si trebuie sa marcheze
        faptul ca ramane cu datorie (field-ul overdue din Contract), sa
        nu mai fie nevoie sa-si caute contractul prin toate contractele
        Distributor-ului

    - Distributor: agrega o lista de Contracte, dar retine si un camp noClients
        > Contractele: Distributorul poate dizolva contracte (metoda
        terminateContracts), pentru ca atunci cand un contract este dizolvat,
        trebuie:
            + Sa fie scos din lista de contracte a Distributor-ului
            + Customer-ul sa fie notificat ca nu mai are contract
            (currContract = null)
        > noClients: se leaga de situaita in care chiar daca unui client i-a
        expirat contractul luna trecuta, el tot este considerat client pentru
        Distributorul respectiv
            + noClients este folosit pentru a calcula costurile ce ii revin
            Distributor-ului la finalul rundei
                - La inceputul rundei, noClients nu ia in considerare
                contractele ce au expirat luna trecuta
                - Pe parcursul rundei, noClients este actualizat atunci cand
                clientii (re)semneaza cu un Distributor

* Support (Abstract Class) -> Producer

Desi aceasta este etapa finala a proiectului, am lasat o portita deschisa in
sensul extinderii codului. Astfel, Support poate fi mostenita in continuare
de entitati precum corpuri de control (ANAF).

    - Producer:
        > distributorList:
            + Se adauga la aceasta in momentul in care distributorii isi aleg
            producatorii (la inceput de luna)
            + Se sterge din aceasta la finalul lunii, atunci cand producatorii
            primesc update-urile lunare
        > monthlyStats:
            + Generate la finalul lunii

* AbstractContract (Abstract Class) -> Contract

    - Contract: contine field-ul overdue (= daca Consumer-ul are datorie)

    - Desi in prima etapa am pastrat in mod intentionat Contract-ul, nu am
    reusit sa extind aceasta clasa astfel:
        > ConsumerContract: contracte distributor-consumator
        > DistributorContract: contracte producator-distributor


* Databases
    - Agrega liste de:
        > Consumer-i        (Consumers)
        > Distributori      (Distributors)
        > Producatori       (Producers) 
    - Bazele de date sunt apelate in situatia in care se efectueaza operatii pe
     toate entitatile (Player-i, Support):
        > La incarcarea si descarcarea datelor (load input, upload output)
        > In game logic: roundUpdatePlayers()

===============================================================================
## Logica programului

* Game.play: pentru fiecare runda:

    - endGameCheck:                 Verifica daca jocul mai poate fi jucat

    - applyPlayerMonthlyUpdates:    Aplica monthlyUpdates jucatorilor 
                                    (pentru rundele 1+)

    - simulateRound:                Actiunile ce au loc in acea runda:
        > roundUpdatePlayers:       Actualizeaza starea jucatorilor
            @Distributori:
                + Se updateaza lista de producatori (cand este cazul)
                + Se recalculeaza costul de productie
                
        > takeTurns:                Fiecare jucator isi indeplineste sarcinile
        > roundUpdateElements:      Actualizeaza starea elementelor 
                                    (contractelor)

    - generateStats:                Se genereaza statisticile cerute, in
                                    acest caz, de producatori

    - applySupportMonthlyUpdates:   Logica simuarii impune aplicarea separata
                                    a update-urilor lunare asupra entitatilor
                                    de tip Support

===============================================================================
## Folosire Design Patterns

* Singleton

Folosit pentru a pastra o singura instanta a bazelor de date. Jocul nu poate
folosi doua baze de date dinstincte de Playeri in acelasi timp

    - Am folosit Singleton pentru:
        > Consumers
        > Distributors

    - Datorita feedback-ului din etapa 1, sunt constient ca aceasta nu este o
    utilizare corecta a Singleton-ului. 
        > In schimb, puteam include acest Singleton in cadrul factory-urilor, 
        intrucat acestea nu aveau nevoie de mai mult de o instanta
        > Totusi, nu am reusit sa ma organizez de asa natura incat sa pot
        modifica acest aspect

* Factory

Folosit pentru a incapsula crearea de Playeri, Contracte si entitati de tip 
Support

    - AbstractContract -> Contract:
        > Apelat in crearea de noi contracte (atunci cand un Consumer semneaza
        cu un Distributor)
    - Player -> Consumer, Distributor
        > Apelat in crearea de noi Playeri (in adaugarea de noi entry-uri in
        bazele de date)
    - Support -> Producer
        > Similar

* Strategy

Folosit pentru a ajuta distributorul sa isi aleaga producatorii

    * EnergyChoiceStrategy (Interf.) -> Green-, Price-, QuantityChoiceStrategy
        - Sortarile prodcatorilor dupa criteriile fiecarei strategii -> streams
        - Interfata permite ca fiecare distributor sa isi poata aplica
        strategia in mod dinamic la runtime

* Observer

Folosit pentru a mapa relatia observator-subiect dintre distributori si 
producatori 

    * La finalul lunii, producatorii sunt updatati => distributorii sunt 
    notificati:
        - Se dizolva relatia dintre producatorul si distributorul respectiv
        - Distributorilor li se seteaza un flag (needsProducers)
    
    * La inceputul lunii urmatoare, distributorii cu flag-ul needsProducers
    isi vor cauta (de la 0) producatori noi

===============================================================================
## Limitari

Pe langa limitarile mentioante la Singleton si la AbstractContract:

    - As fi putut modulariza mai agresiv
    - Este probabil ca testele sa pice din pricina faptului ca nu am 
    replicat logica prezentata in enunt cu suficienta fidelitate

===============================================================================
## Feedback

* Fisiere .ref:
    - In eventualitatea unei teme ce presupune simularea unor runde, recomand
    includerea in arhiva si a unor .ref-uri intermediare (testul 1: runda 1,
    runda 2 etc.).
        > In etapa 1, daca nu binevoiau colegii mei sa imi ofere astfel de 
        .ref-uri, nu eram in stare sa fac tema.