Functions like 'quantity()' should be removed.In favor of GetAttribute(AttrQuantity) see issue #44 about evemu_server HOT 3 CLOSED

I believe it would be wrong design to do that.
Please see positron96@6192c88#commitcomment-2457504 , it is very exemplary. This issue shows the weak point of the GetAttribute approach - it is implementation-specific, it takes the value from table entity_attriutes and that's all. If, for some reason, the needed attribute is in another place, this method will not succeed.
Specific methods, on the other hand, can do whatever code they want, read other database tables, calculate the values on the fly, use some cache mechanism. Specific setter methods can enforce additional checks on the data that user want to store, that would not be appropriate in general SetAttribute method.
Code that uses those specific methods does not care about where are those attributes and how are they obtained, it just calls quanity() and let the method do its magic.
This specific quantity() method cannot be switched to GetAttribute because quantity is not in the attributes table, it's in entity table, as are many properties of other objects.

Generally, that is the whole point of object-oriented language - to hide incapsulated implemetation details and let using code get abstracted from that implementation.

Actually, I've started doing quite the opposite: I'm rewriting Skill class to contain methods like uint8 GetLevel() in positron96@dda76b3 . The only thing it does is call GetAttribute(attrSkillLevel), but it improves usage pattern of the class, makes the code more readable, and, as I said, removes implementation-bindind from code that uses it. I could insert checks in SetLevel() method to make sure level is correct, <=5 for example. I could not do that with SetAttribute approach.

from evemu_server.

I think positron has a VERY good point here and I've felt this for quite a while, just never was able to put it in such stark descriptive words as this implementation-binding exposure, but he's right. Requiring or even exposing the SetAttribute or GetAttribute exposes access directly to the attributes of an item. What that does is take from the owning class the ability to control access to those attributes and manage them internally whilst providing item type appropriate direct calls, as he suggested with SetLevel() on a skill object.

We need more discussion on this to consider possibly expanding the direct calls on all objects and forever hiding the direct Set/Get Attribute access calls that can be made from outside the item class. Perhaps they should be internally accessible only.

-- Aknor

from evemu_server.

this has been updated as part of the major rewrite.
any further discussion should open a new ticket.

from evemu_server.