Enforce noninstantiability with a private constructor

[Rishi Solanki]

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

[taher]

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]

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
> >
>