Just a thought about the Strategy diagram from GoF
3 views
Skip to first unread message
Marco Tedone
Aug 30, 2010, 6:14:42 AM8/30/10
to jpat...@googlegroups.com
I noticed that GoF used aggregation as relationship between the Context
and the Strategy. I don't think this is either necessary nor correct. An
aggregation defines a whole-part relationship (in which the part
lifecycle will survive termination of the whole lifecycle; just for
info, this differ from composition where the lifecycle of the part will
terminate, i.e. it's dependent on, when the whole lifecycle will
terminate). In my view the relationship between the Context and the
Strategy is one of "usage". From the "Unified Modeling Language User
Guide - Booch, Rambaugh, Jacobson, ISBN 0-321-26797-4, page 63: "[...]A
dependency is a relationship that states that one thing [...] uses the
information and services of another thing [...]. Choose dependencies
when you want to show one thing using another.
and the Strategy. I don't think this is either necessary nor correct. An
aggregation defines a whole-part relationship (in which the part
lifecycle will survive termination of the whole lifecycle; just for
info, this differ from composition where the lifecycle of the part will
terminate, i.e. it's dependent on, when the whole lifecycle will
terminate). In my view the relationship between the Context and the
Strategy is one of "usage". From the "Unified Modeling Language User
Guide - Booch, Rambaugh, Jacobson, ISBN 0-321-26797-4, page 63: "[...]A
dependency is a relationship that states that one thing [...] uses the
information and services of another thing [...]. Choose dependencies
when you want to show one thing using another.
So in my view, since the relationship between the Context and the
Strategy could be (and usually is) one where the Context uses the
services/information of the Strategy, it should be depicted as a dotted
line ending with an arrow pointing from Context to Strategy.
Regards,
Marco
Dr Heinz M. Kabutz
Aug 30, 2010, 8:02:23 AM8/30/10
to jpat...@googlegroups.com
A dotted line means "uses" or some other dependency. A solid line means
that there is usually a field in Java that points to the other.
that there is usually a field in Java that points to the other.
The Context uses a Strategy object, but in most cases it also has a
field that points to the instance.
It could be changed to Association, rather than Aggregation, if we start
sharing instances of the Strategy objects between different Contexts,
thus the lifetime of the Strategy objects could exceed the Context. But
as soon as you have state in the Strategy objects (like in Checksum),
you cannot share it, so then the Aggregation is correct.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
http://www.javaspecialists.eu
Tel: +30 69 72 850 460
Skype: kabutz
Dr Heinz M. Kabutz
Aug 30, 2010, 9:04:13 AM8/30/10
to jpat...@googlegroups.com
Going to JavaPolis – err – Devoxx 2010 :-)
We just got notification that our BoF regarding the jpatterns.org annotations has been accepted for Devoxx 2010 in Belgium, the largest Java developers conference in Europe.
At the moment we’ve put Michael Hunger and Heinz Kabutz down as speakers, but please let us know if you are in the area and would also like to join us.
We just got notification that our BoF regarding the jpatterns.org annotations has been accepted for Devoxx 2010 in Belgium, the largest Java developers conference in Europe.
At the moment we’ve put Michael Hunger and Heinz Kabutz down as speakers, but please let us know if you are in the area and would also like to join us.
Alex Gout
Aug 31, 2010, 8:26:37 AM8/31/10
to jpat...@googlegroups.com
Hi,
Great! Should we make a little roadmap so we can focus on the tasks that need to be done by November? What coverage should jpatterns have by then in terms of depth, scope and completeness? I.e. the Alex equation: (D * S * C * Q)/T = Ac
Regards,
Alex
--
You received this message because you are subscribed to the Google Groups "jpatterns" group.
To post to this group, send email to jpat...@googlegroups.com.
To unsubscribe from this group, send email to jpatterns+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jpatterns?hl=en.
Dr Heinz M. Kabutz
Sep 1, 2010, 4:14:32 AM9/1/10
to jpat...@googlegroups.com
Yes, I agree that we should think about this.
1. I think that we need to complete the GoF patterns, which means documenting them and more importantly, writing better tests.
2. Then, I think we should add more JEE patterns.� Marco already started this.� We will need to have a list of patterns that we want to include.� We currently have Business Delegate, DAO and MVC.� All the Core J2EE Patterns 2nd Edition are here:
Presentation Tier:
��� Intercepting Filter
��� Front Controller
��� Context Object
��� Application Controller
��� View Helper
��� Composite View
��� Service To Worker
��� Dispatcher View
Business Tier:
��� Business Delegate (we have that already)
��� Service Locator
��� Session Facade
��� Application Service
��� Business Object
��� Composite Entity
��� Transfer Object
��� Transfer Object Assembler
��� Value List Handler
Integration Tier:
��� Data Access Object (got that already)
��� Service Activator
��� Domain Store
��� Web Service Broker
Some of these patterns are not so relevant to JEE anymore.� The question is: should we make the decision as to what is included or not, or should we just put them all in?� There might be programmers using Transfer Object.� I think that the jee catalog should contain probably at least the above patterns.
MVC is an interesting one, as it is not a JEE pattern as such, but a more general pattern.� We should probably move it somewhere else.� It definitely needs to be somewhere in our catalogs.
3. Then I would think we should also add the Hohpe and Woolf Enterprise Integration Patterns.� We might as well add all of them whilst we're about it.� The more patterns we sport, the more useful jpatterns.org will be to users.� I will write to Gregor and tell him about this - maybe he can send me an electronic list of the patterns and save us some typing...
4. We should also have Fowler's Patterns of Enterprise Application Architecture in our catalog.� Again, I will write to him to ask for an electronic list.
5. I think we should also include some of the PLoPD proceeding patterns in our catalogs.
1. I think that we need to complete the GoF patterns, which means documenting them and more importantly, writing better tests.
2. Then, I think we should add more JEE patterns.� Marco already started this.� We will need to have a list of patterns that we want to include.� We currently have Business Delegate, DAO and MVC.� All the Core J2EE Patterns 2nd Edition are here:
Presentation Tier:
��� Intercepting Filter
��� Front Controller
��� Context Object
��� Application Controller
��� View Helper
��� Composite View
��� Service To Worker
��� Dispatcher View
Business Tier:
��� Business Delegate (we have that already)
��� Service Locator
��� Session Facade
��� Application Service
��� Business Object
��� Composite Entity
��� Transfer Object
��� Transfer Object Assembler
��� Value List Handler
Integration Tier:
��� Data Access Object (got that already)
��� Service Activator
��� Domain Store
��� Web Service Broker
Some of these patterns are not so relevant to JEE anymore.� The question is: should we make the decision as to what is included or not, or should we just put them all in?� There might be programmers using Transfer Object.� I think that the jee catalog should contain probably at least the above patterns.
MVC is an interesting one, as it is not a JEE pattern as such, but a more general pattern.� We should probably move it somewhere else.� It definitely needs to be somewhere in our catalogs.
3. Then I would think we should also add the Hohpe and Woolf Enterprise Integration Patterns.� We might as well add all of them whilst we're about it.� The more patterns we sport, the more useful jpatterns.org will be to users.� I will write to Gregor and tell him about this - maybe he can send me an electronic list of the patterns and save us some typing...
4. We should also have Fowler's Patterns of Enterprise Application Architecture in our catalog.� Again, I will write to him to ask for an electronic list.
5. I think we should also include some of the PLoPD proceeding patterns in our catalogs.
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
On 8/31/10 3:26 PM, Alex Gout wrote:
Hi,
Great! Should we make a little roadmap so we can focus on the tasks that need to be done by November? What coverage should jpatterns have by then in terms of depth, scope and completeness? I.e. the Alex equation: (D * S * C * Q)/T = Ac�
Regards,Alex
On Aug 30, 2010, at 3:04 PM, Dr Heinz M. Kabutz wrote:
Going to JavaPolis � err � Devoxx 2010 :-)
We just got notification that our BoF regarding the jpatterns.org annotations has been accepted for Devoxx 2010 in Belgium, the largest Java developers conference in Europe.
At the moment we�ve put Michael Hunger and Heinz Kabutz down as speakers, but please let us know if you are in the area and would also like to join us.
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
--
You received this message because you are subscribed to the Google Groups "jpatterns" group.
To post to this group, send email to jpat...@googlegroups.com.
To unsubscribe from this group, send email to jpatterns+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jpatterns?hl=en.
Alex Gout
Sep 1, 2010, 3:03:29 PM9/1/10
to jpat...@googlegroups.com
Yes, good list! I agree we should focus first on the GoF patterns.
I'm still concerned about the tests though. In my opinion, the tests now don't seem to test the essence of the annotations. They just test whether or not the piece of code does what we would expect. Therefor, a fail of the test does not in any way indicate an error in the annotation, in all cases it will just be the testcode causing the problem. I dont think that is what a test should be about. The real tests start with whether or not they are applicable to real life code (and even that is very hard to test) and testing the code that will eventually be able to indicate a shady pattern implementation that was annotated with jpatterns.
Untill then, what should we do with our tests as I hope Im not the only one who feels that they do not test jpatterns?
Regards,
Alex
On Sep 1, 2010, at 10:14 AM, Dr Heinz M. Kabutz wrote:
Yes, I agree that we should think about this.
1. I think that we need to complete the GoF patterns, which means documenting them and more importantly, writing better tests.
2. Then, I think we should add more JEE patterns. Marco already started this. We will need to have a list of patterns that we want to include. We currently have Business Delegate, DAO and MVC. All the Core J2EE Patterns 2nd Edition are here:
Presentation Tier:
Intercepting Filter
Front Controller
Context Object
Application Controller
View Helper
Composite View
Service To Worker
Dispatcher View
Business Tier:
Business Delegate (we have that already)
Service Locator
Session Facade
Application Service
Business Object
Composite Entity
Transfer Object
Transfer Object Assembler
Value List Handler
Integration Tier:
Data Access Object (got that already)
Service Activator
Domain Store
Web Service Broker
Some of these patterns are not so relevant to JEE anymore. The question is: should we make the decision as to what is included or not, or should we just put them all in? There might be programmers using Transfer Object. I think that the jee catalog should contain probably at least the above patterns.
MVC is an interesting one, as it is not a JEE pattern as such, but a more general pattern. We should probably move it somewhere else. It definitely needs to be somewhere in our catalogs.
3. Then I would think we should also add the Hohpe and Woolf Enterprise Integration Patterns. We might as well add all of them whilst we're about it. The more patterns we sport, the more useful jpatterns.org will be to users. I will write to Gregor and tell him about this - maybe he can send me an electronic list of the patterns and save us some typing...
4. We should also have Fowler's Patterns of Enterprise Application Architecture in our catalog. Again, I will write to him to ask for an electronic list.
5. I think we should also include some of the PLoPD proceeding patterns in our catalogs.
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
On 8/31/10 3:26 PM, Alex Gout wrote:
Hi,
Great! Should we make a little roadmap so we can focus on the tasks that need to be done by November? What coverage should jpatterns have by then in terms of depth, scope and completeness? I.e. the Alex equation: (D * S * C * Q)/T = Ac
Regards,Alex
On Aug 30, 2010, at 3:04 PM, Dr Heinz M. Kabutz wrote:
Going to JavaPolis – err – Devoxx 2010 :-)
We just got notification that our BoF regarding the jpatterns.org annotations has been accepted for Devoxx 2010 in Belgium, the largest Java developers conference in Europe.
At the moment we’ve put Michael Hunger and Heinz Kabutz down as speakers, but please let us know if you are in the area and would also like to join us.
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
--
You received this message because you are subscribed to the Google Groups "jpatterns" group.
To post to this group, send email to jpat...@googlegroups.com.
To unsubscribe from this group, send email to jpatterns+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jpatterns?hl=en.
--
You received this message because you are subscribed to the Google Groups "jpatterns" group.
To post to this group, send email to jpat...@googlegroups.com.
To unsubscribe from this group, send email to jpatterns+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jpatterns?hl=en.
Dr Heinz M. Kabutz
Sep 1, 2010, 3:13:55 PM9/1/10
to jpat...@googlegroups.com
Hi Alex,
I think we all feel the same way...
I think we all feel the same way...
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
On 9/1/10 10:03 PM, Alex Gout wrote:
Yes, good list! I agree we should focus first on the GoF patterns.I'm still concerned about the tests though. In my opinion, the tests now don't seem to test the essence of the annotations. They just test whether or not the piece of code does what we would expect. Therefor, a fail of the test does not in any way indicate an error in the annotation, in all cases it will just be the testcode causing the problem. I dont think that is what a test should be about. The real tests start with whether or not they are applicable to real life code (and even that is very hard to test) and testing the code that will eventually be able to indicate a shady pattern implementation that was annotated with jpatterns.Untill then, what should we do with our tests as I hope Im not the only one who feels that they do not test jpatterns?
Regards,Alex
�
On Sep 1, 2010, at 10:14 AM, Dr Heinz M. Kabutz wrote:
Yes, I agree that we should think about this.
1. I think that we need to complete the GoF patterns, which means documenting them and more importantly, writing better tests.
2. Then, I think we should add more JEE patterns.� Marco already started this.� We will need to have a list of patterns that we want to include.� We currently have Business Delegate, DAO and MVC.� All the Core J2EE Patterns 2nd Edition are here:
Presentation Tier:
��� Intercepting Filter
��� Front Controller
��� Context Object
��� Application Controller
��� View Helper
��� Composite View
��� Service To Worker
��� Dispatcher View
Business Tier:
��� Business Delegate (we have that already)
��� Service Locator
��� Session Facade
��� Application Service
��� Business Object
��� Composite Entity
��� Transfer Object
��� Transfer Object Assembler
��� Value List Handler
Integration Tier:
��� Data Access Object (got that already)
��� Service Activator
��� Domain Store
��� Web Service Broker
Some of these patterns are not so relevant to JEE anymore.� The question is: should we make the decision as to what is included or not, or should we just put them all in?� There might be programmers using Transfer Object.� I think that the jee catalog should contain probably at least the above patterns.
MVC is an interesting one, as it is not a JEE pattern as such, but a more general pattern.� We should probably move it somewhere else.� It definitely needs to be somewhere in our catalogs.
3. Then I would think we should also add the Hohpe and Woolf Enterprise Integration Patterns.� We might as well add all of them whilst we're about it.� The more patterns we sport, the more useful jpatterns.org will be to users.� I will write to Gregor and tell him about this - maybe he can send me an electronic list of the patterns and save us some typing...
4. We should also have Fowler's Patterns of Enterprise Application Architecture in our catalog.� Again, I will write to him to ask for an electronic list.
5. I think we should also include some of the PLoPD proceeding patterns in our catalogs.
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
On 8/31/10 3:26 PM, Alex Gout wrote:
Hi,
Great! Should we make a little roadmap so we can focus on the tasks that need to be done by November? What coverage should jpatterns have by then in terms of depth, scope and completeness? I.e. the Alex equation: (D * S * C * Q)/T = Ac�
Regards,Alex
On Aug 30, 2010, at 3:04 PM, Dr Heinz M. Kabutz wrote:
Going to JavaPolis � err � Devoxx 2010 :-)
We just got notification that our BoF regarding the jpatterns.org annotations has been accepted for Devoxx 2010 in Belgium, the largest Java developers conference in Europe.
At the moment we�ve put Michael Hunger and Heinz Kabutz down as speakers, but please let us know if you are in the area and would also like to join us.
Alex Gout
Sep 1, 2010, 3:17:15 PM9/1/10
to jpat...@googlegroups.com
oops... I guess I missed a dicussion on my holiday ;)
On Sep 1, 2010, at 9:13 PM, Dr Heinz M. Kabutz wrote:
Hi Alex,
I think we all feel the same way...
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
On 9/1/10 10:03 PM, Alex Gout wrote:
Yes, good list! I agree we should focus first on the GoF patterns.I'm still concerned about the tests though. In my opinion, the tests now don't seem to test the essence of the annotations. They just test whether or not the piece of code does what we would expect. Therefor, a fail of the test does not in any way indicate an error in the annotation, in all cases it will just be the testcode causing the problem. I dont think that is what a test should be about. The real tests start with whether or not they are applicable to real life code (and even that is very hard to test) and testing the code that will eventually be able to indicate a shady pattern implementation that was annotated with jpatterns.Untill then, what should we do with our tests as I hope Im not the only one who feels that they do not test jpatterns?
Regards,Alex
On Sep 1, 2010, at 10:14 AM, Dr Heinz M. Kabutz wrote:
Yes, I agree that we should think about this.
1. I think that we need to complete the GoF patterns, which means documenting them and more importantly, writing better tests.
2. Then, I think we should add more JEE patterns. Marco already started this. We will need to have a list of patterns that we want to include. We currently have Business Delegate, DAO and MVC. All the Core J2EE Patterns 2nd Edition are here:
Presentation Tier:
Intercepting Filter
Front Controller
Context Object
Application Controller
View Helper
Composite View
Service To Worker
Dispatcher View
Business Tier:
Business Delegate (we have that already)
Service Locator
Session Facade
Application Service
Business Object
Composite Entity
Transfer Object
Transfer Object Assembler
Value List Handler
Integration Tier:
Data Access Object (got that already)
Service Activator
Domain Store
Web Service Broker
Some of these patterns are not so relevant to JEE anymore. The question is: should we make the decision as to what is included or not, or should we just put them all in? There might be programmers using Transfer Object. I think that the jee catalog should contain probably at least the above patterns.
MVC is an interesting one, as it is not a JEE pattern as such, but a more general pattern. We should probably move it somewhere else. It definitely needs to be somewhere in our catalogs.
3. Then I would think we should also add the Hohpe and Woolf Enterprise Integration Patterns. We might as well add all of them whilst we're about it. The more patterns we sport, the more useful jpatterns.org will be to users. I will write to Gregor and tell him about this - maybe he can send me an electronic list of the patterns and save us some typing...
4. We should also have Fowler's Patterns of Enterprise Application Architecture in our catalog. Again, I will write to him to ask for an electronic list.
5. I think we should also include some of the PLoPD proceeding patterns in our catalogs.
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
On 8/31/10 3:26 PM, Alex Gout wrote:
Hi,
Great! Should we make a little roadmap so we can focus on the tasks that need to be done by November? What coverage should jpatterns have by then in terms of depth, scope and completeness? I.e. the Alex equation: (D * S * C * Q)/T = Ac
Regards,Alex
On Aug 30, 2010, at 3:04 PM, Dr Heinz M. Kabutz wrote:
Going to JavaPolis – err – Devoxx 2010 :-)
We just got notification that our BoF regarding the jpatterns.org annotations has been accepted for Devoxx 2010 in Belgium, the largest Java developers conference in Europe.
At the moment we’ve put Michael Hunger and Heinz Kabutz down as speakers, but please let us know if you are in the area and would also like to join us.
Dr Heinz M. Kabutz
Sep 1, 2010, 4:03:37 PM9/1/10
to jpat...@googlegroups.com
No problem, Alex - I'd love to hear some suggestions on how we can
improve the situation :-)
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
On 9/1/10 10:17 PM, Alex Gout wrote:
oops... I guess I missed a dicussion on my holiday ;)
On Sep 1, 2010, at 9:13 PM, Dr Heinz M. Kabutz wrote:
Hi Alex,
I think we all feel the same way...
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
On 9/1/10 10:03 PM, Alex Gout wrote:
Yes, good list! I agree we should focus first on the GoF patterns.I'm still concerned about the tests though. In my opinion, the tests now don't seem to test the essence of the annotations. They just test whether or not the piece of code does what we would expect. Therefor, a fail of the test does not in any way indicate an error in the annotation, in all cases it will just be the testcode causing the problem. I dont think that is what a test should be about. The real tests start with whether or not they are applicable to real life code (and even that is very hard to test) and testing the code that will eventually be able to indicate a shady pattern implementation that was annotated with jpatterns.Untill then, what should we do with our tests as I hope Im not the only one who feels that they do not test jpatterns?
Regards,Alex
�
On Sep 1, 2010, at 10:14 AM, Dr Heinz M. Kabutz wrote:
Yes, I agree that we should think about this.
1. I think that we need to complete the GoF patterns, which means documenting them and more importantly, writing better tests.
2. Then, I think we should add more JEE patterns.� Marco already started this.� We will need to have a list of patterns that we want to include.� We currently have Business Delegate, DAO and MVC.� All the Core J2EE Patterns 2nd Edition are here:
Presentation Tier:
��� Intercepting Filter
��� Front Controller
��� Context Object
��� Application Controller
��� View Helper
��� Composite View
��� Service To Worker
��� Dispatcher View
Business Tier:
��� Business Delegate (we have that already)
��� Service Locator
��� Session Facade
��� Application Service
��� Business Object
��� Composite Entity
��� Transfer Object
��� Transfer Object Assembler
��� Value List Handler
Integration Tier:
��� Data Access Object (got that already)
��� Service Activator
��� Domain Store
��� Web Service Broker
Some of these patterns are not so relevant to JEE anymore.� The question is: should we make the decision as to what is included or not, or should we just put them all in?� There might be programmers using Transfer Object.� I think that the jee catalog should contain probably at least the above patterns.
MVC is an interesting one, as it is not a JEE pattern as such, but a more general pattern.� We should probably move it somewhere else.� It definitely needs to be somewhere in our catalogs.
3. Then I would think we should also add the Hohpe and Woolf Enterprise Integration Patterns.� We might as well add all of them whilst we're about it.� The more patterns we sport, the more useful jpatterns.org will be to users.� I will write to Gregor and tell him about this - maybe he can send me an electronic list of the patterns and save us some typing...
4. We should also have Fowler's Patterns of Enterprise Application Architecture in our catalog.� Again, I will write to him to ask for an electronic list.
5. I think we should also include some of the PLoPD proceeding patterns in our catalogs.
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
On 8/31/10 3:26 PM, Alex Gout wrote:
Hi,
Great! Should we make a little roadmap so we can focus on the tasks that need to be done by November? What coverage should jpatterns have by then in terms of depth, scope and completeness? I.e. the Alex equation: (D * S * C * Q)/T = Ac�
Regards,Alex
On Aug 30, 2010, at 3:04 PM, Dr Heinz M. Kabutz wrote:
Going to JavaPolis � err � Devoxx 2010 :-)
We just got notification that our BoF regarding the jpatterns.org annotations has been accepted for Devoxx 2010 in Belgium, the largest Java developers conference in Europe.
At the moment we�ve put Michael Hunger and Heinz Kabutz down as speakers, but please let us know if you are in the area and would also like to join us.
Michael Hunger
Sep 1, 2010, 6:11:34 PM9/1/10
to jpat...@googlegroups.com
The tests don't intent to test the existence or workings of the annotations.
They are there to document the usage of the annotations.
Cheers
Michael
Marco Tedone
Sep 1, 2010, 6:26:57 PM9/1/10
to jpat...@googlegroups.com
Agree
Alex Gout
Sep 2, 2010, 4:30:16 AM9/2/10
to jpat...@googlegroups.com
In that case I feel using JUnit is a bad choice. The tests (asserts) demonstrate the patterns more than jpatterns. Using JUnit strongly suggests semantics the tests dont have. I would suggest then making an examples package to demonstrate the usage instead of a test package that suggests it tests the annotation code.
Marco Tedone
Sep 2, 2010, 5:02:44 AM9/2/10
to jpat...@googlegroups.com
In some environments tests are used to discover and document an api.
Alex Gout
Sep 2, 2010, 5:12:06 AM9/2/10
to jpat...@googlegroups.com
OK, thank you for pointing that out. I wasn't aware of that. It doesn't make me feel better though ;)
Riaan Cornelius
Sep 2, 2010, 9:39:56 AM9/2/10
to jpat...@googlegroups.com
I have to agree with Alex here. I think in this case having an
examples/samples/(something along those lines) package would make more
sense.
examples/samples/(something along those lines) package would make more
sense.
I know tests are often used to document an API as well, but in this case
I do think it is a bit misleading.
Just my 20c
Michael Hunger
Sep 2, 2010, 10:51:19 AM9/2/10
to jpat...@googlegroups.com
For an example we wanted to use the Junit (3) Sources as permitted by Kent Beck annotated with the JPatterns annotations.
Just didn't find time to do it.
Michael
Alex Gout
Sep 2, 2010, 11:47:33 AM9/2/10
to jpat...@googlegroups.com
So I guess there is no point in maintaining / extending our test package, as it will become obsolete anyway once the other examples are in place.
Dr Heinz M. Kabutz
Sep 2, 2010, 11:48:48 AM9/2/10
to jpat...@googlegroups.com
I think every pattern needs an example of how it is intended to be
used. So I think there is a lot of point of doing this.
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
Alex Gout
Sep 2, 2010, 12:40:27 PM9/2/10
to jpat...@googlegroups.com
OK, now Im officially lost. The test package acts as example according to Michael, but also the JUnit3 annotations will act as examples?
Dr Heinz M. Kabutz
Sep 2, 2010, 12:48:21 PM9/2/10
to jpat...@googlegroups.com
The test package contains examples and I would call the JUnit3
annotations as a larger test case that demonstrates how the annotations
can be used in a real project.
Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz
Michael Hunger
Sep 2, 2010, 1:50:43 PM9/2/10
to jpat...@googlegroups.com
I agree with Heinz.
The tests also should show how the patterns work, that they actually work should be proven by the test.
Cheers
Michael
Alex Gout
Sep 2, 2010, 5:22:32 PM9/2/10
to jpat...@googlegroups.com
Yes, this I understand. And that is exactly what I don't like. We use
JUnit to demonstrate the usage of patterns and demonstrate the
jpatterns anotations as a side effect. It just doesn't feel right for
me. Having said that, lets just get on with it, I just wish to express
my feelings about it.
JUnit to demonstrate the usage of patterns and demonstrate the
jpatterns anotations as a side effect. It just doesn't feel right for
me. Having said that, lets just get on with it, I just wish to express
my feelings about it.
Marco Tedone
Sep 3, 2010, 3:58:13 AM9/3/10
to jpat...@googlegroups.com
I don't think we should be testing that the annotation "work", rather use tests to document the annotations. While writing the jee patterns I found that defining all participants as inner classes, types as enums and then documenting each participant through the pattern annotations provided a good mechanism to actually check that all annotations were there. In fact using tdd I used the tests to define the annotations. The purpose of these annotations, as I understood it, it's to document patterns, not to enforce them with some kind of tool which processes our annotations. Also we could do things a step at the time. Let's get the api together and we could build stuff around it afterwards.
From: Alex Gout <ag...@planet.nl>
Sender: jpat...@googlegroups.com
Subject: Re: [jpatterns] Devoxx 2010
Reply all
Reply to author
Forward
0 new messages