4 ms·

So maybe this is nitpicky, but it's the difference between books I buy and books I don't. In the 'Technical Debt and Slop' excerpt, there is an example about d

by LargeWu 13y ago

So maybe this is nitpicky, but it's the difference between books I buy and books I don't. In the 'Technical Debt and Slop' excerpt, there is an example about determining whether an order is free. Basically it compares the customer's store credit plus discounts against the price of the object. It does not account for quantity, or other items in the user's cart. Essentially, the same store credit amount gets applied to every item. This is a bug in the logic, and it took about 30 seconds of me scanning the article to notice it. Now I realize that's not the point of the excerpt. It's about code duplication. But it's still sloppy writing. That's fine for your blog, but if you expect me to pay, I expect content that is of high quality. Code examples should be complete, and free of bugs.

h2s 13y ago
I think you've misunderstood the example code. Each instance of that Order class has exactly one product. There is neither a quantity to consider nor other items in the cart. That may not be the same design as whatever ecommerce system you're used to, but it's definitely the design of this example.
kilburn 13y ago
I think it is worse than that. To begin with, it makes no sense (to me) for an order to have a single product by definition. This is what I think you quickly spotted. I understand that the author does not have an "Order" because that is supposed to be somewhat definitive (a domain object stored in the database). If that is the case, a much better approach would be to have a "PreOrder" object, that is basically the same but lives in the session scope. This PreOrder object (or ShoppingCart, or whatever) should basically "extend" (share everything with) the Order object, inheriting all its capabilities _except that of being persistent_. This includes the logic for computing prices based on discount codes/rates/delivery chargers/whatever that you normally apply to a regular Order. Now, if you want to check if a product would be free, you just add a helper method "free?(product)" to the PreOrder. That method would just get the "price()" of the order, add the product to the PreOrder (itself), check if the new "price()" is higher than before, remove the product, return the result of the price increase check. At this point you have accounted for any possible interaction between product quantities, discount codes and rates, user credit, delivery costs and whatever. No code duplication involved _at all_. Moreover, I would say that it is actually _less_ complex (as in difficult to understand) to build such "PreOrder"s than to add random methods to your domain objects...

by LargeWu 13y ago

h2s 13y ago

I think you've misunderstood the example code. Each instance of that Order class has exactly one product. There is neither a quantity to consider nor other items in the cart. That may not be the same design as whatever ecommerce system you're used to, but it's definitely the design of this example.

kilburn 13y ago

I think it is worse than that. To begin with, it makes no sense (to me) for an order to have a single product by definition. This is what I think you quickly spotted. I understand that the author does not have an "Order" because that is supposed to be somewhat definitive (a domain object stored in the database). If that is the case, a much better approach would be to have a "PreOrder" object, that is basically the same but lives in the session scope. This PreOrder object (or ShoppingCart, or whatever) should basically "extend" (share everything with) the Order object, inheriting all its capabilities _except that of being persistent_. This includes the logic for computing prices based on discount codes/rates/delivery chargers/whatever that you normally apply to a regular Order. Now, if you want to check if a product would be free, you just add a helper method "free?(product)" to the PreOrder. That method would just get the "price()" of the order, add the product to the PreOrder (itself), check if the new "price()" is higher than before, remove the product, return the result of the price increase check. At this point you have accounted for any possible interaction between product quantities, discount codes and rates, user credit, delivery costs and whatever. No code duplication involved _at all_. Moreover, I would say that it is actually _less_ complex (as in difficult to understand) to build such "PreOrder"s than to add random methods to your domain objects...