Refactoring: Split Device class into Device+Protocol#592
Refactoring: Split Device class into Device+Protocol#592rytilahti merged 9 commits intorytilahti:masterfrom
Conversation
…dSender class to separate concerns
3d6c506 to
818089f
Compare
|
@rytilahti Looking forward to hear your feedback when you have a bit of time to review this. Thank you! |
|
@rytilahti friendly ping in case you missed it. If you're busy, that's ok :) |
rytilahti
left a comment
There was a problem hiding this comment.
Hi and sorry for the delay, I added some comments, but my concerns are mostly:
- Users of the device classes should have no need to know about implementation details, that's why the protocol handling should simply by wrapped and invisible to users. (concerns
send()etc.). - For tests, simply pass the existing
self.return_valuesto the dummy implementation directly afterwards. This will keep the history cleaner as there is no real reason to overwrite those parts from my understanding.
Ping @syssi
| "send_cmd": lambda x: self._send_input_validation(x), | ||
| "set_power": lambda x: self._set_power(x), | ||
| } | ||
| ) |
There was a problem hiding this comment.
Please keep the self.return_values for now, and simply pass it as a parameter to the implementation. This will keep the diff much more readable and there is no real need to modify these parts at the moment (imo).
There was a problem hiding this comment.
I was thinking that we don't really need the self.return_values anymore and wanted to clean it up.
The diff is a bit smaller when ignoring whitespaces :badpokerface: https://github.com/rytilahti/python-miio/pull/592/files?w=1
Is that alright?
There was a problem hiding this comment.
Honestly I'd prefer it that'd be done in a separate PR. This PR contains already so many lines to review, and as these are tests, not having return_values does not really bring much.
There was a problem hiding this comment.
Fair enough. I'm initialising the DummyProtocol in DummyDevice now and passing in self so it can access return_values. That way the diff is indeed smaller.
Had to add call to the parent constructor for some dummy devices in tests and add inheritance from DummyDevice, but that should faily uncontroversial :)
Rename do_discover() to send_handshake() & create a proxy method send_handshake() in Device class
| "send_cmd": lambda x: self._send_input_validation(x), | ||
| "set_power": lambda x: self._set_power(x), | ||
| } | ||
| ) |
There was a problem hiding this comment.
I was thinking that we don't really need the self.return_values anymore and wanted to clean it up.
The diff is a bit smaller when ignoring whitespaces :badpokerface: https://github.com/rytilahti/python-miio/pull/592/files?w=1
Is that alright?
dc84f3a to
61afef5
Compare
b382423 to
8509d4d
Compare
|
Actioned the 2nd round of review. Hope it looks better now. Thank you for looking into this, @rytilahti! |
There was a problem hiding this comment.
This start to look good, thanks for your efforts! I'm unsure if cleaning up the DeviceException import should be a part of this, but it's not a big deal. See my comments inline, I haven't yet tested this locally on my devices (I'll do that later this weekend), but otherwise it's almost ready to be merged :-)
miio/device.py
Outdated
| :param str command: Command to send | ||
| :param dict parameters: Parameters to send""" | ||
| return self.send(command, parameters) | ||
| return self.protocol.send(command, parameters) |
There was a problem hiding this comment.
I'm starting to have second thoughts on deprecating the send. This code would generally be much cleaner if we'd keep it as it is, and simply make it wrap the call to the private protocol. Thoughts on this? What are the pros for deprecating it (and making all other methods more complicated)?
There was a problem hiding this comment.
I guess the main reason why I decided to do that was to do less inheritance and more composition (to make things easier to follow). Keeping send, however, makes it more backwards compatible.
I've removed the deprecation.
…od to keep everything compatible. Protocol: update docstring to reflect new code. Vacuum: expose raw_id from the Protocol.
394cb50 to
968f8e1
Compare
|
Done addressing the latest feedback. Tested on my Air Quality Monitor: Discovery worked too: Vacuum (S50) I.e. what I've got works fine, however, I don't have any other devices handy, so further testing will be appreciated! |
rytilahti
left a comment
There was a problem hiding this comment.
I just tested this with the 1st gen vacuum and a powerstrip (zimi.powerstrip.v2). In my opinion this can be merged now, but I'd still like to have the MiIO protocol bits in a separate file already. This will avoid moving the pieces again shortly after introducing the support for miot and keeping the diffs more comprehensible for the future :-)
miio/protocol.py
Outdated
| ) | ||
|
|
||
|
|
||
| class Protocol: |
There was a problem hiding this comment.
Could you move this to its own file (thus, avoid moving this again soonish and polluting the git logs), I'd say miioprotocol.py would be a good candidate.
There was a problem hiding this comment.
✅ Moved Protocol to miioprotocol.py as MiIOProtocol
There was a problem hiding this comment.
Great, thanks for the effort! 🎉
Before adding support for the first MIoT device (#585) I thought it would be good to do a little bit of refactoring (i.e. to make the #585 smaller).
This PR extracts command-sending functionality from Device class to new Protocol class.
send(),discover()anddo_discover()methods were moved fromDevicetoProtocolProtocolis instantiated inDeviceconstructor.Protocol#send()is deprecated & forwards the commands to CommandSender.Note: tried discovery and looks to be working fine:
Edit: renames
CommandSendertoProtocol