[
https://issues.apache.org/jira/browse/OFBIZ-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15337672#comment-15337672 ]
Rishi Solanki commented on OFBIZ-7272:
--------------------------------------
[~pfm.smits]:
Quick References:
{code}
Taher,
Thank you very much for your inputs. I was thinking to do the same to add private constructors first then do other things. But after your reply I think better to pick one class at a time, and check everything for that class which includes removing public modifiers, method and fields. Marking classes members as final and all your suggestions.
We would start picking classes one by one, and check all its references and finally make necessary changes for each class. In that way we would be able to match the classes with purpose. This is better way to fix this design flaw.
Thanks!
Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.comOn Fri, Jun 10, 2016 at 5:00 PM, Taher Alkhateeb <
[hidden email]> wrote:
Hi Rishi,
I would suggest when refactoring such classes to apply everything that has
to do with visibility including:
- Removing public modifiers if not needed on class, method, and field levels
- adding private where appropriate
- marking classes, methods and fields as final where appropriate
- marking method arguments as final where appropriate
So I would consider a private constructor to be just one of a suite of
activites that I call them collectively as visibility and mutability which
are important to provide real isolation between the components with minimal
dependencies.
My 2 cents
Taher Alkhateeb
On Fri, Jun 10, 2016 at 2:22 PM, Rishi Solanki <
[hidden email]>
wrote:
> Dear All,
>
> In past we did same for CatalogWorker, ProductWorker, CategoryWorker, and
> UtilMisc classed. Now I think for all the utility, worker, helper classes
> having only static members are eligible to have an private constructor with
> them to make them non instantiable from anywhere.
>
> We have log an JIra and added patch for the same. So requesting you to take
> a look at OFBIZ-7272 for more details and share your feedback in case we
> can do the same for more classes or if any classes we have added should not
> be in list.
>
> Thanks for your help in advance.
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
>
http://www.hotwaxsystems.com >
{code}
One old ticket id -
https://issues.apache.org/jira/browse/OFBIZ-4656> Enforce noninstantiability to all Utility classes
> -------------------------------------------------
>
> Key: OFBIZ-7272
> URL:
https://issues.apache.org/jira/browse/OFBIZ-7272> Project: OFBiz
> Issue Type: Improvement
> Components: ALL COMPONENTS
> Affects Versions: Trunk
> Reporter: Rishi Solanki
> Assignee: Arun Patidar
> Attachments: OFBIZ-7272.patch
>
>
> I have discusses this in past on mailing list, that Utility, helper, worker classes which contains only static methods should not be instantiable. Also we can restrict it by adding a private constructor.
> Currently OFBiz has many such classes which should have private constructor. Identify all the *Worker.java, *.Helper.java, and *Util.java which do not have any non static method/member are eligible for having a private constructor.
> Reference why we should do this :
http://www.informit.com/articles/article.aspx?p=1216151&seqNum=4--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Locked
