You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bval.apache.org by "Carlos Vara (JIRA)" <ji...@apache.org> on 2010/06/30 15:02:49 UTC
[jira] Created: (BVAL-73) Alternative way of addressing code reuse
issue between the validators
Alternative way of addressing code reuse issue between the validators
---------------------------------------------------------------------
Key: BVAL-73
URL: https://issues.apache.org/jira/browse/BVAL-73
Project: BeanValidation
Issue Type: Improvement
Affects Versions: 0.2-incubating
Reporter: Carlos Vara
Priority: Minor
Attachments: ValidationHelper.diff
Currently, the code reuse issue exposed in BVAL-47 has been solved using a common abstract validator which is subclassed by the jsr303 and core validators.
I have been thinking about how to solve the type safety problems I exposed in my mail. I propose a different solution (no inheritance, and a strategy pattern is used to return the validation flow to the correct method in each validator in a type safe way). The reasons why I propose removing the current inheritance scheme are:
- Inheritance is just used for code reuse. The 2 validatos have different interfaces to which they respond to, and there is no code in which a reference to an "abstract" validator is or should be held.
- I haven't found a way of removing class casting issues with the inheritance strategy. I know that at the moment it is somewhat "easy" to see that most of the casts can't fail, but I find it cleaner and safer to code it in a way in which type safety is enforced by the compiler.
Please take into account that the proposed diff is a preliminar work that simply shows a way in which this could be done. If you prefer this to the current solution with inheritance, further work would be done to better ensure type safety, access to the property treatsMapsLikeBeans would be centralized, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (BVAL-73) Alternative way of addressing code reuse
issue between the validators
Posted by "Carlos Vara (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BVAL-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carlos Vara reassigned BVAL-73:
-------------------------------
Assignee: Carlos Vara
> Alternative way of addressing code reuse issue between the validators
> ---------------------------------------------------------------------
>
> Key: BVAL-73
> URL: https://issues.apache.org/jira/browse/BVAL-73
> Project: BeanValidation
> Issue Type: Improvement
> Affects Versions: 0.2-incubating
> Reporter: Carlos Vara
> Assignee: Carlos Vara
> Priority: Minor
> Attachments: ValidationHelper.diff
>
>
> Currently, the code reuse issue exposed in BVAL-47 has been solved using a common abstract validator which is subclassed by the jsr303 and core validators.
> I have been thinking about how to solve the type safety problems I exposed in my mail. I propose a different solution (no inheritance, and a strategy pattern is used to return the validation flow to the correct method in each validator in a type safe way). The reasons why I propose removing the current inheritance scheme are:
> - Inheritance is just used for code reuse. The 2 validatos have different interfaces to which they respond to, and there is no code in which a reference to an "abstract" validator is or should be held.
> - I haven't found a way of removing class casting issues with the inheritance strategy. I know that at the moment it is somewhat "easy" to see that most of the casts can't fail, but I find it cleaner and safer to code it in a way in which type safety is enforced by the compiler.
> Please take into account that the proposed diff is a preliminar work that simply shows a way in which this could be done. If you prefer this to the current solution with inheritance, further work would be done to better ensure type safety, access to the property treatsMapsLikeBeans would be centralized, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BVAL-73) Alternative way of addressing code reuse
issue between the validators
Posted by "Carlos Vara (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BVAL-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carlos Vara resolved BVAL-73.
-----------------------------
Fix Version/s: 0.2-incubating
Resolution: Fixed
As there is no opposition, I merged a slightly modified version of the patch in rev 962902.
> Alternative way of addressing code reuse issue between the validators
> ---------------------------------------------------------------------
>
> Key: BVAL-73
> URL: https://issues.apache.org/jira/browse/BVAL-73
> Project: BeanValidation
> Issue Type: Improvement
> Affects Versions: 0.2-incubating
> Reporter: Carlos Vara
> Assignee: Carlos Vara
> Priority: Minor
> Fix For: 0.2-incubating
>
> Attachments: ValidationHelper.diff
>
>
> Currently, the code reuse issue exposed in BVAL-47 has been solved using a common abstract validator which is subclassed by the jsr303 and core validators.
> I have been thinking about how to solve the type safety problems I exposed in my mail. I propose a different solution (no inheritance, and a strategy pattern is used to return the validation flow to the correct method in each validator in a type safe way). The reasons why I propose removing the current inheritance scheme are:
> - Inheritance is just used for code reuse. The 2 validatos have different interfaces to which they respond to, and there is no code in which a reference to an "abstract" validator is or should be held.
> - I haven't found a way of removing class casting issues with the inheritance strategy. I know that at the moment it is somewhat "easy" to see that most of the casts can't fail, but I find it cleaner and safer to code it in a way in which type safety is enforced by the compiler.
> Please take into account that the proposed diff is a preliminar work that simply shows a way in which this could be done. If you prefer this to the current solution with inheritance, further work would be done to better ensure type safety, access to the property treatsMapsLikeBeans would be centralized, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (BVAL-73) Alternative way of addressing code reuse
issue between the validators
Posted by "Carlos Vara (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BVAL-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carlos Vara updated BVAL-73:
----------------------------
Attachment: ValidationHelper.diff
> Alternative way of addressing code reuse issue between the validators
> ---------------------------------------------------------------------
>
> Key: BVAL-73
> URL: https://issues.apache.org/jira/browse/BVAL-73
> Project: BeanValidation
> Issue Type: Improvement
> Affects Versions: 0.2-incubating
> Reporter: Carlos Vara
> Priority: Minor
> Attachments: ValidationHelper.diff
>
>
> Currently, the code reuse issue exposed in BVAL-47 has been solved using a common abstract validator which is subclassed by the jsr303 and core validators.
> I have been thinking about how to solve the type safety problems I exposed in my mail. I propose a different solution (no inheritance, and a strategy pattern is used to return the validation flow to the correct method in each validator in a type safe way). The reasons why I propose removing the current inheritance scheme are:
> - Inheritance is just used for code reuse. The 2 validatos have different interfaces to which they respond to, and there is no code in which a reference to an "abstract" validator is or should be held.
> - I haven't found a way of removing class casting issues with the inheritance strategy. I know that at the moment it is somewhat "easy" to see that most of the casts can't fail, but I find it cleaner and safer to code it in a way in which type safety is enforced by the compiler.
> Please take into account that the proposed diff is a preliminar work that simply shows a way in which this could be done. If you prefer this to the current solution with inheritance, further work would be done to better ensure type safety, access to the property treatsMapsLikeBeans would be centralized, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.