"Twenty years from now you will be more disappointed by the things you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover." - Mark Twain
Ashley Bye wrote:I have a class Transaction, which can have many Sales and is reference by a field List<Sale> sales. ... My understanding of the Dependency Inversion principle is that the sale depends on transaction, and not the other way round.
Junilu Lacar wrote: If you consider Transaction as a high-level module and Sales as a low-level module, then DIP says you should introduce an abstraction layer in between Transaction and Sales so that both Sales and Transaction will depend on the abstraction layer instead.
"Twenty years from now you will be more disappointed by the things you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover." - Mark Twain
Ashley Bye wrote:
Ah, got it. So would a correct example of DIP be as follows?
Ashley Bye wrote:I have tried mocking various objects to make this work but I still have no joy, which is why I ask about JPA above. How should I be designing my test, what should and shouldn't be mocked? Also, is this method testable and if not, how would I go about making it so?
Junilu Lacar wrote:In code, that would be:
Junilu Lacar wrote:My rule of thumb is to introduce the interfaces at the "edges" of the hexagonal architecture, which is how most of my designs these days end up.
Junilu Lacar wrote:This kind of test is a 'white box' test because it knows intimate details of how the getSalesFor(Transaction) method works. It's not a bad test to have but you need to recognize that it's more brittle. If you change the implementation of the getSalesFor() method, this test is more likely to fail in some way or become obsolete.
"Twenty years from now you will be more disappointed by the things you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover." - Mark Twain
Ashley Bye wrote:This leads me to think that getSalesFor(Transaction) is not a well designed method. Would it be better to have the method in the TransactionService, so that I am instead sending a message to the Transaction instance referenced like so: transaction.getSales()?
Kent Beck wrote:The ability to create so much business value so quickly was no accident, however. Several factors came into play.
· Method-- Ward and the WyCash team needed to have constant experience growing the design of the system, little by little, so the mechanics of the transformation were well practiced.
· Motive-- Ward and his team needed to understand clearly the business importance of making WyCash multi-currency, and to have the courage to start such a seemingly impossible task.
· Opportunity-- The combination of comprehensive, confidence-generating tests; a well-factored program; and a programming language that made it possible to isolate design decisions meant that there were few sources of error, and those errors were easy to identify.
Ashley Bye wrote:
Is there any reason why the repo is injected into the Transaction?
Something about .... going for a swim. With this tiny ad ...
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
|