• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Parent/child relationship

 
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a parent (Portfolio)/child (Trade) relationship, where each portfolio has 0 or more trades, and each trade has exactly on portfolio.

I currently have this coded as follows :



However this doesn't capture the requirement that Trades always have exactly one Portfolio, ie, parent cannot be null. I would ideally like the code to reflect this knowledge.

The other way I thought to do it is :



I worry that this makes my code less testable as it is more hassle to create trades now.
Also during the trade constructor, portfolio.addTrade() gets called, which isn't ideal (calling parameters methods within a constructor.

After writing this down, I'm beginning to think that the 2nd style is the best.
Does anyone have any views on this and/or patterns that they use to handle this situation?

thanks, Don.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is another idea:



Makes adding a trade a breeze *and* ensures integrity.

As an aside, you might want to use an assert statement instead of your checkPortfolio method:



You need to explicitly enable assertions at runtime to let this have an effect, which might be both an advantage and a disadvantage.
 
Don Kiddick
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks for the reply.

With that example you can still call "new Trade()" independently of a portfolio though, leaving the parent null.

I'm beginning to think option 2 (trade constructor takes a portfolio) is my preffered one.

What is the advantage of using an assert over IllegalArguementException? I think I always want my assertions on.

thanks, Don.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Don Kiddick:
With that example you can still call "new Trade()" independently of a portfolio though, leaving the parent null.

I'm beginning to think option 2 (trade constructor takes a portfolio) is my preffered one.



Right. What I actually wanted to write was




What is the advantage of using an assert over IllegalArguementException? I think I always want my assertions on.



Mostly less code, as far as I can tell...
 
Don Kiddick
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja, thanks for your time.
Don.
 
Don Kiddick
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One thing I've noticed using the assert keyword is that it's really hard to test using junit that they are thrown.

e.g.



I don't know if this is a junit 4.0 thing, but fail() now throws a AssertionError, thus making this test always pass!
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Never occurred to me... I typically don't think of asserts as expected behavior (just like logging), so I don't write tests for them.

But I guess you could also rewrite the test as



As an aside, since JUnit 4 I prefer my test method names to read more like specification of behaviour (BDD-like), for example "throwsExceptionWhenNameIsInvalid".
 
Don Kiddick
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yeah was wondering about that, seeing as we don't have to prepend test to our test methods anymore.
 
On top of spaghetti all covered in cheese, there was this tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic