API Optimization

[yannicschroeer]

Well. I noticed that I duplicate a lot of shit and had the find method in the Repository, even though it should be a base repository method. In the companyService for example, I didn't use the Repository at all but just the BaseRepository, as our update and create methods are very explicit. That said, we can straight increment to v2 😂👋

[yannicschroeer]

Lets maybe also discuss how to use this. If I'd like to override the signature of a repository function e.g. the create method on the BookingRepository, I'd do the following:

    def create(self, event_id: int, customer_id: int, event_location_selection: EventLocation, is_confirmed: bool = False) -> BookingModel:
        logger.info("Booking creation", event_id=event_id)
        booking = BookingModel(event_id=event_id, customer_id=customer_id, event_location_selection=event_location_selection, is_confirmed=is_confirmed)
        return super(BookingRepository, self).create(booking)

Any objections? Improvement suggestions?

[JonasScholl]

Well... 😂 LGTM😄

[JonasScholl]

Any objections? Improvement suggestions?

calling ’create’ of the super class makes sense 👍 however, it is violating the LSP because the signature is changing... To be really clean you'd have to create another method or another independant class that uses the repository from the lib. But I'm still uncertain what makes sense here

[yannicschroeer]

Any objections? Improvement suggestions?

calling ’create’ of the super class makes sense 👍 however, it is violating the LSP because the signature is changing... To be really clean you'd have to create another method or another independant class that uses the repository from the lib. But I'm still uncertain what makes sense here

Is it really violating the LSP? My interpretation of the principle is, that anything is allowed as long as the signature is extended but not narrowed. You can put an object of the structure X(a,b) within an object of the structure Y(a,b,c) vice versa is not possible, but thats also not part of the principle. Main statement is: any object should be placable within its superclass without affecting the correctness of the programming (my opinion)

[JonasScholl]

Any objections? Improvement suggestions?

calling ’create’ of the super class makes sense 👍 however, it is violating the LSP because the signature is changing... To be really clean you'd have to create another method or another independant class that uses the repository from the lib. But I'm still uncertain what makes sense here

Is it really violating the LSP? My interpretation of the principle is, that anything is allowed as long as the signature is extended but not narrowed. You can put an object of the structure X(a,b) within an object of the structure Y(a,b,c) vice versa is not possible, but thats also not part of the principle. Main statement is: any object should be placable within its superclass without affecting the correctness of the programming (my opinion)

maybe I missed something there, but the signature of create in the base class is

def create(self, entity: GenericEntity) -> GenericEntity:

and the one of the subclass could be something like this:

def create(self, event_id: int, customer_id: int, event_location_selection: EventLocation, is_confirmed: bool = False) -> BookingModel:

That doesn't extend the signature, it's different

[yannicschroeer]

Any objections? Improvement suggestions?

calling ’create’ of the super class makes sense 👍 however, it is violating the LSP because the signature is changing... To be really clean you'd have to create another method or another independant class that uses the repository from the lib. But I'm still uncertain what makes sense here

Is it really violating the LSP? My interpretation of the principle is, that anything is allowed as long as the signature is extended but not narrowed. You can put an object of the structure X(a,b) within an object of the structure Y(a,b,c) vice versa is not possible, but thats also not part of the principle. Main statement is: any object should be placable within its superclass without affecting the correctness of the programming (my opinion)

maybe I missed something there, but the signature of create in the base class is

def create(self, entity: GenericEntity) -> GenericEntity:

and the one of the subclass could be something like this:

def create(self, event_id: int, customer_id: int, event_location_selection: EventLocation, is_confirmed: bool = False) -> BookingModel:

That doesn't extend the signature, it's different

Fair point 😅 so what's the (pythonic) approach to go? Generic *args and **kwargs signature? 😅

[JonasScholl]

Fair point 😅 so what's the (pythonic) approach to go? Generic *args and **kwargs Signature? 😅

Where do you want to use them? In the base implementation we need the entity argument anyways, no? I don't see a clean OOP way to solve this by overriding the same method. You would either have to create / implement another method or create some factory for it

[yannicschroeer]

Where do you want to use them? In the base implementation we need the entity argument anyways, no? I don't see a clean OOP way to solve this by overriding the same method. You would either have to create / implement another method or create some factory for it

Factory seems reasonable to me. I (as a user) don't want to reimplement everything via facades to use this. Are you with that?

[JonasScholl]

Factory seems reasonable to me. I (as a user) don't want to reimplement everything via facades to use this. Are you with that?

yep, sounds good 👍