Skip to main content
added 146 characters in body
Source Link
Doc Brown
  • 214k
  • 34
  • 394
  • 603

If you need some serialization code which is specific for certain Handler implementations, my first choice would be to make it part of the type itself (i.e. derive the handler directly from interface HandlerSerialize) and hence put it into the same module where the specific Handler lives, so either (core or extension). I would not discard that solution so quickly just because of a superstitious feeling of being "not correct" - in case the serialization code requires access to private members, it may be simply the most straightforward solution.

If the serialization code is separable from the specific Handler type (which means it does not need access to non-public members), and core and extension become so large maintenance gets confusing, you may introduce two new modules coreSerializers and extensionSerializers and put the code there. As always, introducing more structure comes for the price for increased management efforts, so I would recommend against starting with this design - better refactor to this structure when the code base grows in this area.

Generic serialization code like HandlerSerializer<T: Handler>, however, can be placed in a neutral location, since it does not create a dependency on specific handler implementation. It could by either placed in persistence or in some new module serialization, whatever you prefer.

If you need some serialization code which is specific for certain Handler implementations, my first choice would be to make it part of the type itself and hence put into the same module where the specific Handler lives, so either core or extension. I would not discard that solution so quickly just because of a superstitious feeling of being "not correct".

If the code is separable from the Handler type, and core and extension become so large maintenance gets confusing, you may introduce two new modules coreSerializers and extensionSerializers and put the code there. As always, introducing more structure comes for the price for increased management efforts, so I would recommend against starting with this design - better refactor to this structure when the code base grows in this area.

Generic serialization code like HandlerSerializer<T: Handler>, however, can be placed in a neutral location, since it does not create a dependency on specific handler implementation. It could by either placed in persistence or in some new module serialization, whatever you prefer.

If you need some serialization code which is specific for certain Handler implementations, my first choice would be to make it part of the type itself (i.e. derive the handler directly from interface HandlerSerialize) and hence put it into the same module where the specific Handler lives (core or extension). I would not discard that solution so quickly just because of a superstitious feeling of being "not correct" - in case the serialization code requires access to private members, it may be simply the most straightforward solution.

If the serialization code is separable from the specific Handler type (which means it does not need access to non-public members), and core and extension become so large maintenance gets confusing, you may introduce two new modules coreSerializers and extensionSerializers and put the code there. As always, introducing more structure comes for the price for increased management efforts, so I would recommend against starting with this design - better refactor to this structure when the code base grows in this area.

Generic serialization code like HandlerSerializer<T: Handler>, however, can be placed in a neutral location, since it does not create a dependency on specific handler implementation. It could by either placed in persistence or in some new module serialization, whatever you prefer.

added 338 characters in body
Source Link
Doc Brown
  • 214k
  • 34
  • 394
  • 603

If you need some serialization code which is specific for certain Handler implementations, my first choice would be to make it part of the type itself and hence put into the same module where the specific Handler lives, so either core or extension. I would not discard that solution so quickly just because of a superstitious feeling of being "not correct".

If the code is separable from the Handler type, and you have the impression core and extension become so large itmaintenance gets confusing, you may introduce two new modules coreSerializers and extensionSerializers and put the code there. As always, introducing more structure comes for the price for increased management efforts, so I would recommend against starting with this design - better refactor to this structure when the code base grows in this area.

Generic serialization code like HandlerSerializer<T: Handler>, however, can be placed in a neutral location, since it does not create a dependency on specific handler implementation. It could by either placed in persistence or in some new module serialization, whatever you prefer.

If you need some serialization code which is specific for certain Handler implementations, my first choice would be to make it part of the type itself and hence put into the same module where the specific Handler lives, so either core or extension.

If the code is separable from the Handler type, and you have the impression core and extension become so large it gets confusing, you may introduce two new modules coreSerializers and extensionSerializers.

Generic serialization code like HandlerSerializer<T: Handler>, however, can be placed in a neutral location, since it does not create a dependency on specific handler implementation. It could by either placed in persistence or in some new module serialization, whatever you prefer.

If you need some serialization code which is specific for certain Handler implementations, my first choice would be to make it part of the type itself and hence put into the same module where the specific Handler lives, so either core or extension. I would not discard that solution so quickly just because of a superstitious feeling of being "not correct".

If the code is separable from the Handler type, and core and extension become so large maintenance gets confusing, you may introduce two new modules coreSerializers and extensionSerializers and put the code there. As always, introducing more structure comes for the price for increased management efforts, so I would recommend against starting with this design - better refactor to this structure when the code base grows in this area.

Generic serialization code like HandlerSerializer<T: Handler>, however, can be placed in a neutral location, since it does not create a dependency on specific handler implementation. It could by either placed in persistence or in some new module serialization, whatever you prefer.

Source Link
Doc Brown
  • 214k
  • 34
  • 394
  • 603

If you need some serialization code which is specific for certain Handler implementations, my first choice would be to make it part of the type itself and hence put into the same module where the specific Handler lives, so either core or extension.

If the code is separable from the Handler type, and you have the impression core and extension become so large it gets confusing, you may introduce two new modules coreSerializers and extensionSerializers.

Generic serialization code like HandlerSerializer<T: Handler>, however, can be placed in a neutral location, since it does not create a dependency on specific handler implementation. It could by either placed in persistence or in some new module serialization, whatever you prefer.