This is a continuation blog. Please read Part 1 first, before reading this.
Version 2: Component Based
Let’s say that the data is no longer a dictionary or something that isn’t readily serialized by XML or JSON modules.
For simplicity sake, let’s just create an object version of the data in part 1:
Complex Data
Usual Suspects
If you’re advanced, you might say “well, I would just use the __dict__ property of the class since it contains the properties!”
Okay, that would work if you’re serializing it to JSON. However, that would fail when you use that on the XML parser.
Component Serialization
An alternative solution is to put the serialization logic within the component itself.
Here’s the modified class with the serialization logic:
Caveat
Of course, this option isn’t always available or advisable. For example, on existing (usually vendor-supplied) APIs, or even those written by other teams where you don’t have control over, this might not be feasible.
But if you’re writing a framework and has some level of control, you could do this approach and just requires the component-developers to provide their own serialization via a render method and that would be it.
Engine Code
The engine is now simpler since it delegates the actual serialization to the components.
The advantage is that future components and new formats can be supported by the engine long after this is deployed and nothing needs to be updated in the engine itself.
Here’s the simple render code of the engine:
We just call the render method of the object and return whatever value it returns.
This will also catch any error raised by the component.
Sample Use Case
Here’s how we’d combine all these ideas.
We instantiate the component object then the engine.
We then call the component objects render method, passing different formats to it to test them all.
Here’s the output for the code above:
Component Implementation Summary
As mentioned, this is just another option for implementing extensible and/or extendable data formatting in your applications.
Both approaches have their own PROS and CONS and it’s up to you to decide which one makes sense to what you’re doing.
Engine-based
PROS
- Easy to implement.
- You have control as to which format to support.
- Advanced implementations can make it easy to extend dynamically.
CONS
- You’ll have to know complex objects to serialize them properly.
- Changes are done on the engine side when modifying or adding the render logic.
Component-based
PROS
- Component owners decide/defines how to serialize their objects.
- Doesn’t require change in Engine when owners decide to change the render logic.
- Allows Engine to support very complex data types.
CONS
- Requires certain level of control on the infra or system in order to enforce correctly.
- Doesn’t allow for generic serialization (since each component must write their own) *
* unless you create a base-class and implement the render method here, so that all implementations of this base-class essentially carries with it the serialization logic.
Source Codes
You may download the source codes used in this blog from this link:
https://github.com/vegitz/codes/tree/master/0032%20Implementing%20Data%20Formatter%20Python