Fwd: Enforce noninstantiability with a private constructor

[Rishi Solanki]

Moving thread to dev list.

All, we have started effort on this under OFBIZ-7272. In that effort we
found some classes isn't in use. Once completed this effort we will share
them for discussion so that we can decide weather to keep them in OFBiz or
we are good to remove them.


--
Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com

---------- Forwarded message ----------
From: Rishi Solanki <[hidden email]>
Date: Fri, Jun 10, 2016 at 7:40 PM
Subject: Re: Enforce noninstantiability with a private constructor
To: ofbizuser <[hidden email]>


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: [phone]
http://www.hotwaxsystems.com

On 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: [phone]
> > http://www.hotwaxsystems.com
> >
>

[Rishi Solanki]

Team,

We have started pushing changes into trunk, in case anyone would like to
review then we are keeping it very simple;
- For any class we have an sub ticket with class name.
- On the ticket description we are posting the changes needs to be done,
then discuss and finalize the changes.
- Upload the patch with same finalized changes and edit the ticket's
description accordingly.

If you would like to review, then commit, patch and ticket description all
are same so that can be reviewed easily. Thanks!


Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com

On Sat, Jun 18, 2016 at 7:56 PM, Rishi Solanki <[hidden email]>
wrote:

> Moving thread to dev list.
>
> All, we have started effort on this under OFBIZ-7272. In that effort we
> found some classes isn't in use. Once completed this effort we will share
> them for discussion so that we can decide weather to keep them in OFBiz or
> we are good to remove them.
>
>
> --
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
>
> ---------- Forwarded message ----------
> From: Rishi Solanki <[hidden email]>
> Date: Fri, Jun 10, 2016 at 7:40 PM
> Subject: Re: Enforce noninstantiability with a private constructor
> To: ofbizuser <[hidden email]>
>
>
> 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: [phone]
> http://www.hotwaxsystems.com
>
> On 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: [phone]
>> > http://www.hotwaxsystems.com
>> >
>>
>
>
>