Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

11

31.07.2013, 16:06

Zitat

Wieso muss der Goldwert von außen direkt geändert werden? Wenn dem so ist, wieso ist er dann in der Klasse?

Beispiel Szenario Spieler trifft auf NPC , NPC schenkt Spieler Gold, dann würde ich eben in der NPC klasse das Gold des Spielers erhöhen.


Das ganze befindet sich in dieser Klasse weil ich gerne einen zentralen Spot habe , der mir das abspeichern erleichtert, damit eine klasse alle wichtigen Daten des Spielers zentral abspeichern kann.

Vielleicht versteh ich auch die Frage nich ganz :huh:

Zitat

Ein get allein ist auch nicht weiter tragisch, wenn man nicht überall
auch ein set hat. Die Frage von dot ist allerdings noch nicht ganz
beantwortet. Wenn es darum geht zu wissen, wie viel Gold der Spieler
hat, klar, warum kein "getAmountOfGold()" (anstatt "getGold()", denn das
sollte ja das Gold des Spielers an sich zurückliefern und nicht nur die
Anzahl seiner Münzen) und eine "giveGold(amount)" und
"seizeGold(amount)" Methoden?
Ja soweit wie es jetzt ist wären Get()/set() Methoden auch noch eine Lösung , da es nur ca. 5 Eigenschaften gibt , jedoch kommen im laufe der Entwicklung viele hinzu , bzw. sind eingeplant und ich komme nicht umhin 50 get und 50 set Methoden für einen schlechten Programmierstil zu halten.

H5::

Treue Seele

Beiträge: 368

Wohnort: Kiel

  • Private Nachricht senden

12

31.07.2013, 16:59

Also meiner Meinung gehört Gold nicht zum Spieler sondern sollte abstrakter sein. Ob jetzt getter/setter gut oder schlecht sind ist wohl eher Geschmackssache, ich benutze sie in der Form get... set... selbst nicht aber sofern sie wenn dann auch konsequent seingesetzt werden stören sie mich auch nicht. Ich mag wenn dann lieber eine Art Property Syntax + Named Parameter Idom.

Zu deiner Frage, ich würde versuchen die Angelegenheit etwas zu Abstrahieren, in etwa wie folgt ( Auf die schnelle auch nicht besonders chic, aber ich denke es zeigt was ich meine. ) :

C-/C++-Quelltext

1
#include <map>

C-/C++-Quelltext

1
2
3
4
5
6
enum class Item
{
    Gold,
    Foo,
    Bar
};

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
class Inventory
{
private: // -- instance member
    std::map<Item, signed> data_;

private: // -- instance methods
public:
    auto add( Item item, unsigned value = 1 ) -> signed
    {
        data_[item] += value;

        return data_[item];
    }

    auto remove( Item item, unsigned value = 1 ) -> signed
    {
        data_[item] -= value;

        return data_[item];
    }

    auto amount( Item item ) const -> signed
    {
        auto iter = data_.find( item );

        if ( data_.end( ) == iter )
        {
            return 0;
        }

        return iter->second;
    }
};

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class Player
{
private: // -- instance member
    Inventory inventory_;

private: // -- instance methods
public:
    auto loot( Item item, unsigned value ) -> void
    {
        inventory_.add( item, value );
    }

    auto lose( Item item, unsigned value) -> void
    {
        inventory_.remove( item, value );
    }

    auto has( Item item, unsigned value = 1) const -> bool
    {
        return inventory_.amount( item ) >= value;
    }
};

Benutzbar wäre es dann z.B. so.:

C-/C++-Quelltext

1
2
3
4
5
6
Player player;
player.loot( Item::Gold, 100 );
if ( player.has( Item::Gold, 20 ) )
{
    player.lose( Item::Gold, 20 );
}
:love: := Go;