[
https://issues.apache.org/jira/browse/OFBIZ-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548530
]
Jonathon Wong commented on OFBIZ-1485:
--------------------------------------
> UtilProperties treats FlexibleProperties as a generic Properties object.
That's the concept of abstraction. Introduce an additional layer
(FlexibleProperties) between UtilProperties and Properties. Idea is to decouple
UtilProperties from Properties, so that the underlying implementation of
Properties can be swapped easily. Like now, for example. You want a FastMap,
just change FlexibleProperties. UtilProperties don't need change, nor do any
codes that use UtilProperties. Abstraction. Decoupling. Pluggable architecture.
What happens when you want to change FastMap to UltraMap in future? You'd need
to change UtilProperties, and possibly even codes that use UtilProperties.
Maybe UltraMap has some new ultra interfaces that FastMap doesn't have.
Don't teach the driver to drive differently. Teach the car! Whether the car has
an old fuel injection system (FastMap) or a new nano-spray injection system
(UltraMap), the driver still steps on the gas pedal the same as always. The gas
pedal could be your abstraction layer, the FlexibleProperties.
Even if FlexibleProperties add little value now, it should still be retained as
an insulation layer between UtilProperties and Properties. It's not always a
step forward to reduce the number of classes, especially in object-oriented
programming where abstraction is useful.
> those Maps use Generics to enforce the Key is String and Value is String
> constraints
"Generics" is a class? Interface?
The fact that you are making Maps perform extra acrobatics for such enforcement
already tells you that a "specialization" is needed. Rather than making a very
special Map that acts like Properties, isn't it more logical to make a
FastProperties?
> If a piece of code MUST have a Properties object, one can be constructed from
> a FastMap by using the Properties.putAll(...) method.
Then you're teaching the driver to steer different. You wanted legacy codes (or
existing users of those methods) to avoid change, right? Or not? Don't we want
to benefit more (with fast FastMap) and work less (less change propagation)?
If a piece of code does not have a Properties object (which is what you're
suggesting now), there is a chance that a non-string "property" will get
inserted into the Map object. Somewhere down the line, something will fail,
logics get compounded, and problems become convoluted.
Consider the "fail-fast" strategy that reduces programming errors and increases
deterministic program flow.
The OFBiz framework is very very well-done by solid OO programmers (delegators,
pluggable view handlers, wow!). Continue the tradition? :)
Is the solution I suggested very problematic? I thought it got us all the
benefit (with FastMap) and none of the hassle (users of UtilProperties need
zero change)? What is the objective here, actually?
> UtilProperties - The Next Generation
> ------------------------------------
>
> Key: OFBIZ-1485
> URL: https://issues.apache.org/jira/browse/OFBIZ-1485
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
> Reporter: Adrian Crum
> Priority: Minor
> Attachments: props_tng.patch
>
>
> Improve the UtilProperties class. Details in comments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
