You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Rishi Solanki <ri...@gmail.com> on 2011/11/15 15:08:25 UTC
Enforcing noninstantiability to Utility Classes in OFBiz
Hello Team,
Recently I came across the guideline given for the Utility classes by
Joshua Bloch (Effective Java author).
Quick Reference -
http://www.informit.com/articles/article.aspx?p=1216151&seqNum=4
Now I have a question on the pattern we are using for the most of the
utility classes which only have the static methods, mentioning few of them
here;
- CatalogWorker.java
- CategoryWorker.java
- ProductWorker.java
- UtilMisc.java
etc.
Here in any of the class we do not have the instance methods/attributes,
and user (client) of these class may try to instantiate the object of these
class as default constructor auto applies to them, also some may tries to
extend them to add their own utility methods. We should fix this, that
means in OFBiz we do not take such kind of patch or code which will create
the instance of these classes, but we should also enforce the client of
these classes to do not instantiate and extends these classes.
We in OFBiz tries to do this in some classes like StringUtil.java by
enforcing the singleton property with the private constructor, but the
final instance of StringUtil have been used in FreeMarkerWorker.
Please let me know your thoughts on this, and if agree then I will create
Jira and submit the patch.
--
Rishi Solanki
Manager, Enterprise Software Development
HotWax Media Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxmedia.com
Re: Enforcing noninstantiability to Utility Classes in OFBiz
Posted by Rishi Solanki <ri...@gmail.com>.
Hi,
I have created Jira issue and provided patch here -
https://issues.apache.org/jira/browse/OFBIZ-4656
Sorry for delay in action.
--
Rishi Solanki
Manager, Enterprise Software Development
HotWax Media Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxmedia.com
On Wed, Nov 16, 2011 at 4:47 PM, Rishi Solanki <ri...@gmail.com>wrote:
> Thanks Adrian, I will submit the patch by this week.
> I hope this is fine.
>
>
> --
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Media Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxmedia.com
>
>
> On Tue, Nov 15, 2011 at 8:02 PM, Adrian Crum <
> adrian.crum@sandglass-software.com> wrote:
>
>> That sounds good to me. I have noticed other places in OFBiz where a
>> utility class has been used improperly, but at the moment I can't think of
>> where those are.
>>
>> Feel free to upload patches to Jira. All code improvements are welcome!
>>
>> -Adrian
>>
>>
>> On 11/15/2011 2:08 PM, Rishi Solanki wrote:
>>
>>> Hello Team,
>>> Recently I came across the guideline given for the Utility classes by
>>> Joshua Bloch (Effective Java author).
>>> Quick Reference -
>>> http://www.informit.com/**articles/article.aspx?p=**1216151&seqNum=4<http://www.informit.com/articles/article.aspx?p=1216151&seqNum=4>
>>>
>>> Now I have a question on the pattern we are using for the most of the
>>> utility classes which only have the static methods, mentioning few of
>>> them
>>> here;
>>> - CatalogWorker.java
>>> - CategoryWorker.java
>>> - ProductWorker.java
>>> - UtilMisc.java
>>> etc.
>>>
>>> Here in any of the class we do not have the instance methods/attributes,
>>> and user (client) of these class may try to instantiate the object of
>>> these
>>> class as default constructor auto applies to them, also some may tries to
>>> extend them to add their own utility methods. We should fix this, that
>>> means in OFBiz we do not take such kind of patch or code which will
>>> create
>>> the instance of these classes, but we should also enforce the client of
>>> these classes to do not instantiate and extends these classes.
>>> We in OFBiz tries to do this in some classes like StringUtil.java by
>>> enforcing the singleton property with the private constructor, but the
>>> final instance of StringUtil have been used in FreeMarkerWorker.
>>>
>>> Please let me know your thoughts on this, and if agree then I will create
>>> Jira and submit the patch.
>>>
>>> --
>>> Rishi Solanki
>>> Manager, Enterprise Software Development
>>> HotWax Media Pvt. Ltd.
>>> Direct: +91-9893287847
>>> http://www.hotwaxmedia.com
>>>
>>>
>
Re: Enforcing noninstantiability to Utility Classes in OFBiz
Posted by Rishi Solanki <ri...@gmail.com>.
Thanks Adrian, I will submit the patch by this week.
I hope this is fine.
--
Rishi Solanki
Manager, Enterprise Software Development
HotWax Media Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxmedia.com
On Tue, Nov 15, 2011 at 8:02 PM, Adrian Crum <
adrian.crum@sandglass-software.com> wrote:
> That sounds good to me. I have noticed other places in OFBiz where a
> utility class has been used improperly, but at the moment I can't think of
> where those are.
>
> Feel free to upload patches to Jira. All code improvements are welcome!
>
> -Adrian
>
>
> On 11/15/2011 2:08 PM, Rishi Solanki wrote:
>
>> Hello Team,
>> Recently I came across the guideline given for the Utility classes by
>> Joshua Bloch (Effective Java author).
>> Quick Reference -
>> http://www.informit.com/**articles/article.aspx?p=**1216151&seqNum=4<http://www.informit.com/articles/article.aspx?p=1216151&seqNum=4>
>>
>> Now I have a question on the pattern we are using for the most of the
>> utility classes which only have the static methods, mentioning few of them
>> here;
>> - CatalogWorker.java
>> - CategoryWorker.java
>> - ProductWorker.java
>> - UtilMisc.java
>> etc.
>>
>> Here in any of the class we do not have the instance methods/attributes,
>> and user (client) of these class may try to instantiate the object of
>> these
>> class as default constructor auto applies to them, also some may tries to
>> extend them to add their own utility methods. We should fix this, that
>> means in OFBiz we do not take such kind of patch or code which will create
>> the instance of these classes, but we should also enforce the client of
>> these classes to do not instantiate and extends these classes.
>> We in OFBiz tries to do this in some classes like StringUtil.java by
>> enforcing the singleton property with the private constructor, but the
>> final instance of StringUtil have been used in FreeMarkerWorker.
>>
>> Please let me know your thoughts on this, and if agree then I will create
>> Jira and submit the patch.
>>
>> --
>> Rishi Solanki
>> Manager, Enterprise Software Development
>> HotWax Media Pvt. Ltd.
>> Direct: +91-9893287847
>> http://www.hotwaxmedia.com
>>
>>
Re: Enforcing noninstantiability to Utility Classes in OFBiz
Posted by Adrian Crum <ad...@sandglass-software.com>.
That sounds good to me. I have noticed other places in OFBiz where a
utility class has been used improperly, but at the moment I can't think
of where those are.
Feel free to upload patches to Jira. All code improvements are welcome!
-Adrian
On 11/15/2011 2:08 PM, Rishi Solanki wrote:
> Hello Team,
> Recently I came across the guideline given for the Utility classes by
> Joshua Bloch (Effective Java author).
> Quick Reference -
> http://www.informit.com/articles/article.aspx?p=1216151&seqNum=4
>
> Now I have a question on the pattern we are using for the most of the
> utility classes which only have the static methods, mentioning few of them
> here;
> - CatalogWorker.java
> - CategoryWorker.java
> - ProductWorker.java
> - UtilMisc.java
> etc.
>
> Here in any of the class we do not have the instance methods/attributes,
> and user (client) of these class may try to instantiate the object of these
> class as default constructor auto applies to them, also some may tries to
> extend them to add their own utility methods. We should fix this, that
> means in OFBiz we do not take such kind of patch or code which will create
> the instance of these classes, but we should also enforce the client of
> these classes to do not instantiate and extends these classes.
> We in OFBiz tries to do this in some classes like StringUtil.java by
> enforcing the singleton property with the private constructor, but the
> final instance of StringUtil have been used in FreeMarkerWorker.
>
> Please let me know your thoughts on this, and if agree then I will create
> Jira and submit the patch.
>
> --
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Media Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxmedia.com
>