Symulacja banku (Pomocy)

Question

Ma ktoś może pomysł jak sprawić aby "pieniądze" z jednej tablicy były odejmowane i trafiały do drugiej. Wiem, że można zrobić : gotowkagraczy[x] = gotowkagraczy[x] - przelew; gotowkagraczy[x] = gotowkagraczy[x] - przelew; , ale jak zrobić, żeby wykryto o jakiego gracza chodzi (bo może być ich do pięciu). Czy jest opcja bez robienia switch'y lub if'ów.

Mój kod:

int gotowkagraczy[8], przelew, przelewod, przelewdo;

            cout<<"Wybierz ilość przelewanych pieniędzy: ";                       cin>>przelew;
            cout<<"Wybierz gracza któremu pieniądze maja być odjęte: ";    cin>>przelewod;
            cout<<"Wybierz gracza któremu pieniądze maja być dodane: ";   cin>>przelewdo;

Co dalej?

Answer 1

Używając pętli wystarczy jeden warunek sprawdzenia, któremu graczowi zostaną przelane pieniądze, jednak w jaki sposób rozróżnić poszczególnych graczy? Wydaje mi się, że najprostszym narzędziem będzie struktura, czyli taki zbiór składowych/typów, w naszym przypadku dwóch. Niech to będą imię i pieniądze na koncie. Właściwie to tablica struktur, bo oczekujemy, że graczy będzie kilku, pozwól, że przedstawię Ci coś takiego:

#include <iostream>

using namespace std;

struct gracz {
    string imie;
    int pieniadze;
};

int main() {
    const int ROZMIAR = 3;
    string nazwa;
    int przelew;
    gracz przyjaciele[ROZMIAR] = {{"Kamil", 2300},
                                  {"Piotr", 3450},
                                  {"Maria", 2600}};
    cout << "Dane przyjaciol: " << endl;
    for (int i = 0; i < ROZMIAR; i++)
        cout << przyjaciele[i].imie << " " << przyjaciele[i].pieniadze << endl;
    cout << "Komu przelac pieniadze i ile: " << endl;
         cin >> nazwa >> przelew;
    for (int i = 0; i < ROZMIAR; i++)
        if (nazwa == przyjaciele[i].imie)
            przyjaciele[i].pieniadze += przelew;
    cout << "Po transakcji:" << endl;
    for (int i = 0; i < ROZMIAR; i++)
        cout << przyjaciele[i].imie << " " << przyjaciele[i].pieniadze << endl;
    return 0;
}

Comments

Znalazłem łatwiejsze rozwiązanie

cout<<tr("Podaj ilość przelewanych pieniędzy: "); int przelew; cin>>przelew;
      cout<<tr("Wybierz gracza, który przelewa(oddaje): "); int od; cin>>od;
      for(int z=0; z!=od; )
{
    z++;
    cout<<z;
    Sleep(2000);
    if(z==od)
        kasa[z]-=przelew;
}

 

Answer 2

Najprościej to obiektowo, jeśli oczywiście potrafisz.

Comments

Niestety nie.

---

podejście obiektowe nie jest zawsze najlepsze

---

A kiedy nie jest?

---

Tworzenie dodatkowych zależności
Należy dążyć do unikania tworzenia nadmiernej liczby powiązań pomiędzy elementami programu. Dziedziczenie tworzy w gruncie rzeczy aż trzy zależności pomiędzy klasami i są zależności obustronne. Po pierwsze, zamierzona, czyli rozszerzanie klasy bazowej i wykorzystanie jej funkcjonalności we własnej klasie. Niestety, o ile na diagramie <<extends>> to jedna strzałeczka, o tyle przy realizacji tego przez dziedziczenie dochodzą jeszcze dwie niechciane. Klasa dziedzicząca staje się zależna nie tylko od interfejsu klasy bazowej, ale także od jej konkretnego zachowania. W sumie każde użycie klasy powoduje powstanie takiej zależności, ale w przypadku dziedziczenia jest ona o tyle istotna, że bardzo łatwo zapomnieć o tym, że zachowanie klasy bazowej może się zmienić, i oprzeć się na fałszywych założeniach co do niego. Szczególnie łatwo o taką sytuację, gdy klasa bazowa nie zachowuje pełnej enkapsulacji i coś przez protected przechodzi do klasy pochodnej albo nie ma w ogóle żadnego zabezpieczenia na poziomie języka (np. Python, PHP4). Druga strzałeczka idzie w przeciwną stronę i jest o wiele boleśniejsza: klasa bazowa zaczyna być zależna od klasy dziedziczącej. Autor klasy bazowej nie ma już swobody w jej modyfikacji, bo nagle może się okazać, że zmieniając coś w swojej klasie, zepsuje klasę dziedziczącą. Problem? Jeśli skojarzysz, że istnieją projekty większe niż 10-klasowe zabawki z laborek, ktorych po zakończeniu zajęc nie trzeba już utrzymywać, to okaże się, że tak - i to spory. Oprócz wymienionych wyżej problemów pojedynczych strzałek, dochodzi oczywiście ten bardziej globalny: cykl w grafie zależności.

Dziedziczenie tworzy relację między klasami
Dziedziczenie (lub niektóre jego formy - zależy od języka*) wprowadzają relację JEST pomiędzy klasą dziedziczącą a bazową. A o tym, i wynikających z tego wymogach, zbyt wielu programistów - szczególnie początkujących - po prostu kompletnie zapomina. Jednak pamiętanie o problemie może niewiele zmienić, bo żeby mieć pewność, że wszystko zostało poprawnie przeimplementowane, trzeba znać szczegóły implementacji klasy bazowej. Inaczej nie da się przewidzieć, jakie zależności istnieją między elementami klasy, a tym samym, co w ogóle trzeba zmienić. Bo nie, często nie wystarczy przedefiniować tylko interesującej nas metody. Jedyną sytuacją, w której ta ostatnia kwestia nie występuje, jest przypadek klasy, która była jawnie przeznaczona przez autora do dziedziczenia. Wtedy oczywiście jest w dokumentacji napisane, co należy zmieniać. W przeciwnym przypadku ląduje się jednak w poprzednim paragrafie. Oczywiście można przedefiniować wszystkie metody, co jest sposobem struprocentowo pewnym, ale to trochę mija się z celem, dla którego stosowane jest dziedziczenie.

Dziedziczenie niechcianego zachowania
Dziedzicząc przyjmujesz wszystko, co zawiera klasa bazowa. Także rzeczy, które potencjalnie mogą ci do niczego nie być potrzebne. Ładnym przykładem są strumienie w C++. Cały mechanizm ich działania wymaga istnienia obiektu bufora. Niezależnie od tego, czy bufor ten jest do czegoś potrzebny, jakakolwiek klasa mająca implementować np. std::ostream będzie zawierała cały kod i dane związane z jego obsługą. A na co na przykład implementacji ignorującej wszystkie otrzymywane dane** to wszystko, skoro istotnym jest tylko, by metoda zapisująca natychmiast wracała, nie wykonując żadnych dodatkowych czynności? Należy tutaj zauważyć, że źródłem problemu jest nie wybór osoby implementującej klasę dziedziczącą, lecz decyzja autora klasy bazowej, który narzucił innym sposób rozwiązania rozszerzania.

Klasy nie przeznaczone do dziedziczenia
Kolejna sprawa, o której łatwo zapomnieć - czy po klasie bazowej w ogóle można dziedziczyć? Bardzo często... nie. Przyczyną mogą być na przykład kwestie czysto technicznych (np. brak virtual w przypadku C++) lub decyzje autora klasy, która zostałaby użyta jako bazowa. Programista może - zakładając brak dziedziczenia - wykonać optymalizacje zakładające znajomość faktycznego typu obiektów. W momencie, gdy typ ten będzie inny, wszystko może się posypać. Z takimi przypadkami akurat łatwo spotkać się już przy początku nauki. Poczatkujący - nie w celu uzasadnionej optymalizacji, lecz ze zwykłej niewiedzy i niedoświadczenia - nagminnie dublują kod w klasach i robią założenia co do faktycznego typu np. argumentów funkcji.

Jezeli ktos nie zna obiektowki, a pisze w tym paradygmacie to kod jest gorszy od proceduralnego 

---

Przy mniejszych projektach składających się z kilku klas może problem nie nastąpić. Ale przy większych może się okazać, że programista stworzy 50 klas i każda będzie zależna od siebie, a w pliku źródłowym main.cpp będzie trzeba includować 50 nagłówków funkcji, co nie powinno mieć miejsca.