> This sounds more interesting to me. Seems like such a simple OO approach would be cleaner than either manual mapping + class generation or annotations (that don't tell you which arguments the method can take and what return values are expected).
> If you group them all into a single LifecycleCallbacks > interface, though, then yeah, you'd want default methods and call them > blindly (they would either do nothing -- the default -- or run the object's > lifecycle code). That was the idea. The assumption being that learning a single interface can be easier that 7 different interfaces. Need to test the practicality of it though. Maybe one interface per callback is a less "weird" way of doing it. > One possible advantage of annotations is you could include > several @PostAdd-annotated methods, but then you'd potentially have calling > order issues. Yep, this is the advantage that quickly becomes a disadvantage. > When we did post-adds, we'd put all the changes in one method > or have that one method call smaller ones in-order. That's exactly how I would do it, no need for extra abstractions. Andrus > On Jul 5, 2022, at 6:55 PM, Michael Gentry <blackn...@gmail.com> wrote: > > On Tue, Jul 5, 2022 at 11:46 AM Andrus Adamchik <aadamc...@gmail.com> wrote: > >> Now that "default" implementations of interface methods are possible... >> > > This sounds more interesting to me. I'm assuming you mean a separate > interface per callback? Something like PostAddLifecyleCallback? You > wouldn't need a default method implementation in that case. If you > implement the interface, you should implement the method. It'll also be > easier for Cayenne to test if the object implements a given lifecycle > interface. If you group them all into a single LifecycleCallbacks > interface, though, then yeah, you'd want default methods and call them > blindly (they would either do nothing -- the default -- or run the object's > lifecycle code). > > One possible advantage of annotations is you could include > several @PostAdd-annotated methods, but then you'd potentially have calling > order issues. When we did post-adds, we'd put all the changes in one method > or have that one method call smaller ones in-order. I think I'd prefer the > certainty of a single method (via interface) than random annotation > orderings. Of course, can always throw a runtime error if more than one > method has the same annotation, but I think not having that error at > runtime is a better approach.
