Coupling alternative about betterpython HOT 3 CLOSED

Hi Alex, my apologies - I wasn't watching the Github issue section so I completely overlooked your post here. The suggestions you make for updating the code are really nice. In particular, the dataclasses really help make the code much cleaner. I'm actually looking into doing a more in-depth video about dataclasses and how to use them and this is a perfect example so I'll surely refer to that in the video.

Eventually, something like tax computation could also be a good candidate for a Strategy pattern, if tax computation becomes more complicated than just computing a percentage, but putting it in an enum is already better than my version :).

I think, after your improvements, the Application class is not even needed anymore since the registration is just a few lines of code now:

vehicle = Vehicle(
    make="Volkswagen",
    model="ID3",
    price=35000,
    tax_bracket=PropulsionTax.ELECTRIC,
)
vehicle.id, vehicle.license = self.registry.random_id()

print("Registration complete. Vehicle information:")
print(self.vehicle)

Anyway - thanks for your thoughts on this, and my apologies for not replying sooner!

from betterpython.

Thanks for your reply. I had actually missed an issue like that before, too. Kind of backwards how there's no email notifications for issues in owned repositories.

And this, on the module level, is a good change:

vehicle.id, vehicle.license = self.registry.random_id()

Excited for a video on dataclasses!

Towards that, maybe tax should be a (read-only) property. Having it in __post_init__ works, but if e.g. price changes, the object state is out of sync since tax won't get updated. So it should definitely be a dynamic property, which dataclasses can do easily:

@dataclass
class Vehicle:
    make: str
    model: str
    price: int
    tax_bracket: PropulsionTax

    # Straight from the factory, doesn't have any of these yet:
    id: Union[str, None] = None
    license: Union[str, None] = None

    @property
    def tax(self):
       return self.price * self.tax_bracket.value

Much better, but now tax is no longer part of the repr. That's possibly for the better, since the repr is supposed to mimic the class call to construct an instance, and tax isn't part of that. Trying to get a property into a dataclass field seems to get ugly quickly. I guess that's when dataclasses break down and their value (terseness, readability, saved boilerplate) is diminished.

from betterpython.

I actually suspect that the Github email notifications work as they should for owned repositories, however in that same period my email was moved over from Google to Microsoft and I think a few incoming mails were lost during that transition .

Dataclasses are really useful, but indeed it seems they do not play well with properties, see also this post.

from betterpython.