CODEWITHSUNDEEP
pythonclass
Ryan Davies
Ryan Davies

Reputation: 616

Is there anything wrong with referencing an instance variable without implementing a getter?

In a nutshell, I receive json events via an API and recently I've been learning a lot more about classes. One of the recommended ways to use classes is to implement getters, setters etc.. However, my classes aren't too sophisticated all they're doing is parsing data from a json object and passing better formatted data onto further ETL processes.

Below is a simple example of what I've encountered.

data = {'status': 'ready'}


class StatusHandler:
    def __init__(self, data):
        self.status = data.get('status', None)


class StatusHandler2:
    def __init__(self, data):
        self._status = data.get('status', None)

    @property
    def status(self):
        return self._status


without_getter = StatusHandler(data)
print(without_getter.status)

with_getter = StatusHandler2(data)
print(with_getter.status)

Is there anything wrong with me using the class StatusHandler and referencing a status instance variable and using that to pass information forward to other bits of code? I'm just wondering if further down the line as my project gets more complicated that this would be an issue as it doesn't seem to be standard although I could be wrong...

Upvotes: 0

Views: 33

Answers (1)

bruno desthuilliers
bruno desthuilliers

Reputation: 77912

The point of getters/setters is to avoid replacing plain attributes access with computed ones without breaking client code if and when you have to change your implementation. This only make sense for languages that have no support for computed attributes.

Python has a quite strong support for computed attributes thru the descriptor protocol, including the generic builtin property type, so you don't need explicit getters/setters - if you have to change your implementation, just replace affected public attributes by computed ones.

Just make sure to not abuse computed attributes - they should not make any heavy computation, external resource access or so. No one expects what looks like an attribute to have a high cost or raise IOErrors or so ;-)

EDIT

With regard to your example: computed attributes are a way to control attribute access, and making an attribute read-only (not providing a setter for your property) IS a perfectly valid use case - IF you have a reason to make it read-only of course.

Upvotes: 2

Related Questions