justification for using factories ] FTTP parser

* Justification for moving scan4Uplink() from FTTPCktLoader.java into UplinkFactory.java:
* Indeed it was proven functionally acceptable to leave scan4Uplink() in FTTPCktLoader. However, this new design offers several potential benefits and follows a few design principles.
* – encapsulating changes. Lots of potential changes are now isolated to this class. Look at the “business logic” in this factory, and you may agree it can change.
* – cohesion. It’s best to make one class responsible for one thing only. This factory is relatively high-cohesion — responsible for instantiating UplinkPort and nothing else. FTTPCktLoader is low-cohesion — already responsible for many things, and do not need to take care of UplinkPort instantiation. If a class is responsible for 2 relatively unrelated things, we can get too many changes.
* – readability. Thanks to cohesion, this class is clearly self-contained, not entangled. Left in FTTPCktLoader.java, this code would appear to be interdependent with other methods.
* – testability. Left in FTTPCktLoader.java, you can test this code too, but not as a unit-test.
* – extensibility. It’s easy to add functionalities into this factory.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s