理解“行为”和方法的放置

Question

I would like to better understand how to structure methods in a simple inventory manager program that has inheritance.

Context: products in a retail environment are assigned a location when not on the sales floor. Think of the location as a divided bookshelf with rows and columns, like this:

An action the program must execute is adding a product to a location. Such as assigning the red star to location 10/2/3 in the graphic above. My question is, is this a 'behavior/method' of the worker, the bin, or the product? When you think in terms of execution, how do you decide which class? The worker can put the product...the product can be placed ...and the bin can receive . It seems that it could be implemented in all 3.

My mind wants to tell me that I should implement this at the bin level as the bin should ultimately be in-charge of what gets placed in it. For example, when it receives a request to store an item it makes sure it isn't storing an improper product, or a non-product. Get what I mean?

What about the argument that the product could be responsible to check itself to make sure it's proper and even the worker ensuring it has a proper product?? Something tells me that perhaps there should be a super form of validation and then each one implements its own version of it?

Maybe I'm not thinking about this correctly. How do you think about it? Am I over simplifying it? Under simplifying? Are there rules for this sort of thing or a best practice?

Answer 1

The real answer is "it depends". I think many developers struggle with this early on.

It also depends on the ever changing requirements. Your first solution may make lots of sense initially but not make sense 2 years later as you implement new features.

My best recommendation is to purchase (or borrow) a copy of Martin Fowler's book on Refactoring and read his Movie Rental example in the (I believe) first chapter. He shows a simple example and how he refactors it over time due to changing requirements. (His trivial example exhibits some of the same concerns you express. Should the rental class, movie class, or customer class handle which requirements.) Not only should you read his example, you should follow along in your own IDE. And you should attempt to work it on your own to see what you come up with given the same changing requirements.

This might start to give you a sense of what things to worry about initially and how to adapt your code over time. You'll make mistakes and learn to recognize "bad smells" in your code. This will inform your design decisions in the future. The book also will help you address those bad smells that you already have.

Here's a link: http://refactoring.com