I must be missing something in the way things should be designed. In C# the property would be access like a field. however in C++ I have to do functions which work differently when accessed from other objects.
I guess i could do:
1 2
public:
int MaxHP;
But that feels like I am sort of defeating the purpose.
@naraku9333: That won't work because "???::MaxHP" will not have access to "???'s" members unless it had a "???" object to reference. However, you could change it a little:
@naraku9333:
The way i currently have it would be more effective then this. Simply because I need to be able to modify the value of the "character" object without overwritting it.
In C# I would have my other object access that data using the properties like so:
1 2
hero.MaxHP += 5; // when adding a magical item.
hero.MaxHP -= 5; // when removing same item.
However, so far, to do the same thing in C++, I've been stuck with the examples above in my original post.
@Framework:
I like your example as it help me learn something new, however, for what I wish to do, I would sooner just use public fields. Simply because I have a lot of these fields which have to be accessed and modified by other objects and I don't want to complicate my code too much. However every book I've read and studied, always discourage using public fields like so. Which causes my dilemma.
> I have a lot of these fields which have to be accessed and modified by other objects
¿what about letting the one that has the information, to handle the data?
1 2 3 4 5
hero.MaxHP += 5; // when adding a magical item.
hero.MaxHP -= 5; // when removing same item.
//or simply
hero.add_item( ring );
> We're using "friend" here to prevent setters and to tighten encapsulation
The inner class is private...
Yes, I know it's private; I don't know how the OP's class is meant to function, so I assumed private. Regardless of level of access, it's still tightens encapsulation.
If your going to do that you might as well make the variable public.
Not at all. This cant be access directly, you have to create a temp int& in the other object to manipulable it. Also That's just my original dilemma, properties in C# make things as if they were public, but they aren't, they still have a private backing field. However your right and I agree that you might as well use a public field, but every book I've studied, say not to do so. However, properties, or that function I just showed, both gives the ability to add more code that can alter things. While the public field is just a field.
I was not planning on doing this originally, but I've considered what I could do with the above exemple;
@ne555:
I guess that would be another great way of doing it. However with my code already made a certain way, I don't know if i want to change it now. Though I might, as I could probably have more functionality.