Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/114 class of property #115

Merged
merged 2 commits into from Jul 17, 2018
Merged

Conversation

robert-bor
Copy link
Contributor

#114 Beanfield class determined by how it will be accessed

Currently, the field property always determines the class of a
BeanProperty. This leads to confusing and faulty behaviour when the
method accessors differentiate from the field, leading, for example,
to the wrong BeanConverters being chosen or the wrong casts being made.
The behaviour should be legitimate, since the developer may choose to
map within a class. BeanMapper must make use of the access knowledge to
determine the class of the BeanProperty.

A BeanProperty will have a notion of how it will be accessed for its role
(either source or target). The possibilities are: field, getter, setter
or no access. The access type will have an influence on the reported
class of the beanfield.

When a BeanProperty is created, it will immediately build up its
understanding of the way its property will be accessed and the class
it must return upon being queried.

The creation process for BeanProperty instances has been abstracted into
its own class. The set of static methods was hard to test and convoluted
with its relatively large number of parameters that is being passed
around.

Structural use of BeanField has been renamed to BeanProperty; a bean
field is one of the two ways a property may be accessed, the other is
through its method accessor (get/set). The property is the combination
of its field and method accessors.

A collection list will no longer be offered for clear/reuse when the
class type of the accessor method differs from the class type of the
field.

@codecov
Copy link

codecov bot commented Jul 14, 2018

Codecov Report

Merging #115 into master will decrease coverage by 0.3%.
The diff coverage is 89.85%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master     #115      +/-   ##
============================================
- Coverage     94.05%   93.75%   -0.31%     
- Complexity      808      844      +36     
============================================
  Files            81       87       +6     
  Lines          1700     1776      +76     
  Branches        162      173      +11     
============================================
+ Hits           1599     1665      +66     
- Misses           60       67       +7     
- Partials         41       44       +3
Impacted Files Coverage Δ Complexity Δ
...nmapper/core/collections/MapCollectionHandler.java 81.81% <ø> (ø) 6 <0> (ø) ⬇️
...mapper/core/converter/impl/PrimitiveConverter.java 93.75% <ø> (ø) 5 <0> (ø) ⬇️
...apper/exceptions/BeanPropertyNoMatchException.java 100% <ø> (ø) 1 <0> (?)
...anmapper/core/converter/AbstractBeanConverter.java 94.73% <ø> (ø) 9 <0> (ø) ⬇️
...er/core/collections/AbstractCollectionHandler.java 92.3% <ø> (+5.64%) 12 <0> (-1) ⬇️
...r/core/converter/impl/NumberToNumberConverter.java 92% <0%> (ø) 11 <4> (ø) ⬇️
...o/beanmapper/core/BeanPropertyAccessException.java 0% <0%> (ø) 0 <0> (?)
...anmapper/core/inspector/FieldPropertyAccessor.java 71.42% <0%> (ø) 15 <0> (ø) ⬇️
...apper/core/generics/AbstractBeanPropertyClass.java 100% <100%> (ø) 3 <3> (?)
...beanmapper/core/generics/DirectedBeanProperty.java 100% <100%> (ø) 9 <9> (?)
... and 33 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f2c2329...e77a5dc. Read the comment docs.

@robert-bor robert-bor force-pushed the feature/114-class-of-property branch from b6c9f6c to e77a5dc Compare July 16, 2018 09:35
Currently, the field property always determines the class of a
BeanProperty. This leads to confusing and faulty behaviour when the
method accessors differentiate from the field, leading, for example,
to the wrong BeanConverters being chosen or the wrong casts being made.
The behaviour should be legitimate, since the developer may choose to
map within a class. BeanMapper must make use of the access knowledge to
determine the class of the BeanProperty.

A BeanProperty will have a notion of how it will be accessed for its role
(either source or target). The possibilities are: field, getter, setter
or no access. The access type will have an influence on the reported
class of the beanfield.

When a BeanProperty is created, it will immediately build up its
understanding of the way its property will be accessed and the class
it must return upon being queried.

The creation process for BeanProperty instances has been abstracted into
its own class. The set of static methods was hard to test and convoluted
with its relatively large number of parameters that is being passed
around.

Structural use of BeanField has been renamed to BeanProperty; a bean
field is one of the two ways a property may be accessed, the other is
through its method accessor (get/set). The property is the combination
of its field and method accessors.

A collection list will no longer be offered for clear/reuse when the
class type of the accessor method differs from the class type of the
field.
@42BV 42BV deleted a comment Jul 16, 2018
@42BV 42BV deleted a comment Jul 16, 2018
@42BV 42BV deleted a comment Jul 16, 2018
@42BV 42BV deleted a comment Jul 16, 2018
@robert-bor robert-bor merged commit 9ce5bd8 into master Jul 17, 2018
@robert-bor robert-bor deleted the feature/114-class-of-property branch July 17, 2018 10:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants