You are completely right! I made the mistake by manual intervention when moving the blog content from its former location. All the code in the blog was supposed to be invariant to this refactoring. Didn’t have proper tests in place!

Cheers, Rafael

if (simultaneous >= 3 && simultaneous >= 7) {

Should read:

if (simultaneous >= 3 && simultaneous <= 7) {

Interesting ideas though.

eh, programming is risky, so i would never say less needs to be tested, so i don’t see that as such a solid argument.

however, more ‘atomic’ classes will make things like “who changed this and why?” studies easier in our version control system, and will make it easier to reuse such classes in other contexts perhaps. (the latter going for or against yagni depending on your interpretation of it.)

sincerely.

Thanks again for the comments.

The price and frequent points concerns are already separated by distinct value object functions. When necessary they can be further isolated to distinct value object classes.

We should always be able to adapt the domain model in order to explicitly reproduce the new business reasoning.

If the calculation rules change fundamentally, I would first try to preserve the current solution benefits, by defining new corresponding unified and meaningfully parameterised functions.

Only if the first approach proves inviable, I would consider a class hierarchy and the strategy design pattern.

Cheers,
Rafael

With point 1 what I meant was that, and again this comes down to YAGNI and what the current requirements state, ideally these 2 concepts would not be tied together.
For example imagine the charge algorithm changes (e.g. takes into consideration how many movies are already out) then the RentalConditions class will be modified and although the code for renter points is not modified it needs to be re-tested even though it only depends on initialTerm and extraPoints. Ideally these 2 concern would be separated.

Regarding the alternative design benefit comment, I know what you are trying to say but for this (deliberately) narrow design example its not obvious to see the benefits. One could argue that the first design is easier to change as although the current requirements make the algorithm be duplicated in multiple places, a future requirement which changes in a different way (not using the parameters int the RentalConditions class i.e. initialTerm etc) for only one ‘type’ of movie (say NewReleases). The NewReleases class changes and the others are left alone.

With the alternative design we would have to either subclass the Value Object and use a Factory to build the correct ‘version’ of the RentalConditions class.

Again I look forward to your next article.
Cheers

Thanks for your comments. They helped me clarify my article.

Now my specific comments about your comments:

–> “1. The RentalConditions have tied together 2 concepts (price and renter points) which most likely have different rates of change.”

The RentalConditions are (immutable) value objects. They never change, they are just replaced by new ones whenever necessary. Therefore, the also called Single Responsibility Principle doesn’t apply here.

–> “2. The concept of ‘movie classification’ is not explicit in both versions which plays a role in deciding what the price is.”

You are right. We will focus our attention on this relevant concept in the next post.

–> “the new design does not really exhibit any real benefit over the first”

The benefits from the alternative design are stated in the Conclusions.

Greetings,
Rafael

Nice post.
I generally agree with you and I know that this is a simple example and that the context is very important when coming up with alternate designs.

There are a few issues with your implementation though (and admittedly with the initial implementation).

1. The RentalConditions have tied together 2 concepts (price and renter points) which most likely have different rates of change. (Kent Beck talks about this in his book Implementation Patterns).
2. The concept of ‘movie classification’ is not explicit in both versions which plays a role in deciding what the price is.

An alternative design could be a double dispatch model (as the business rules will most likely not sit with just one object).
A movie could have a classification and the price determined by the rental type and the movie classification. There may be a monthly rental contracts, yearly etc which would affect pricing.

Yes admittedly the requirements are not there but this is just an example to show that the new design does not really exhibit any real benefit over the first. They are both pretty easy to understand and change although your design is more parametrized which ties more closely to open-closed principle.

So for completeness, an example of the double dispatch design which would be suitable say if the decision of price varies over more than one type of object i.e. by movie type and rental type…(in Smalltalk)

rental price.

Rental>>price
^aMovie classification priceForRental: self.

Classification>>priceFor: rentalDetails
self subclassResponsibility.

NewReleaseMovie>>priceFor: rentalDetails
^rentalDetails priceForNewRelease.

ChildrenMovie>>priceFor: rentalDetails
^rentalDetails priceForChildrenMovie.

RegularMovie>>priceFor: rentalDetails
^rentalDetails priceForRegularMovie.

Good article though and I agree with your sentiments behind DDD.

Thanks also for then shout out in your post – it’s always a pleasant surprise to find my name or blog mentioned at another site!