The current idea of the observer interface depends on the mutable behavior of the Type\WpImport{TYPE} objects. This has two downsides:
it forces the Importer instances to actual call $importType->id( $new_id ); which breaks encapsulation.
it is overall redundant. We can solve each task (primarily the ID mapping) by simply listening to the w2m_{TYPE}_imported actions.
Further, the current Import\Data\IdObserverInterface is limited to be used for all types. Listeners to single types are not designated, which violates the interface-segregation principle.
along with that there are Import\Data\ImportTermListenerInterface, Import\Data\ImportUserListenerInterface and of course Import\Data\ImportCommentListenerInterface.
The Import\Data\IdObserverInterface will be replaced by Import\Data\ImportListenerInterface which is just a »semantic« interface and extends all these new four types:
The current idea of the observer interface depends on the mutable behavior of the
Type\WpImport{TYPE}
objects. This has two downsides:$importType->id( $new_id );
which breaks encapsulation.w2m_{TYPE}_imported
actions.Further, the current
Import\Data\IdObserverInterface
is limited to be used for all types. Listeners to single types are not designated, which violates the interface-segregation principle.The refactored structure:
along with that there are
Import\Data\ImportTermListenerInterface
,Import\Data\ImportUserListenerInterface
and of courseImport\Data\ImportCommentListenerInterface
.The
Import\Data\IdObserverInterface
will be replaced byImport\Data\ImportListenerInterface
which is just a »semantic« interface and extends all these new four types:This requires also a refactoring of
Import\Data\PresetUserTypeIdMapper
,Import\Data\ImportListeningTypeIdMapper
andController\DataIdObserverProvider
.