implement vending application

[s ravi chandran]

Junilu Lacar wrote:

s ravi chandran wrote:
We can have add return true as a response for a successful add and false for a failure in add product. that way, we will only deal with add and not the products.

Ok, we can explore that option. At this point, I would commit whatever changes I've made so far into source control, like Git or SVN. Then we can either switch off the keyboard so you can drive or I can keep driving and you can navigate me through the changes. What test do you want to write for this API change? Obviously, our current test will have to be deleted or changed.

Considering that I am just starting off. I would say better you drive it. We can discuss the changes being made so that I get to know what and why some design changes were made.

[Junilu Lacar]

Ok. Is this the kind of test code you had in mind with the change to the add API?

	@Test
	public void should_be_able_to_add_items_to_sell() {
		VendingMachine testSubject = new VendingMachine();
		boolean added = testSubject.add("Slot1", "M&Ms", 5);
		assertThat(added, is(true)); 
	}

[Junilu Lacar]

Let's see if refactoring this is better:

    @Test  
    public void should_be_able_to_add_items_to_sell() {  
        VendingMachine testSubject = new VendingMachine();  
        assertThat(testSubject.add("Slot1", "M&Ms", 5), is(true));  
    }

What do you think?

[Junilu Lacar]

What about the String parameters for slot and productName? Are you good with these or do you think they should be a different type? Should we consider having fewer parameters? How would that work? Are there other alternatives to the API design that we can consider?

[s ravi chandran]

Junilu Lacar wrote:What about the String parameters for slot and productName? Are you good with these or do you think they should be a different type? Should we consider having fewer parameters? How would that work? Are the other alternatives to the API design that we can consider?

I was actually using

 assertTrue(testSubject.add("Slot1", "M&Ms", 5) )

in my code. I guess either way, its fine. Product Name is better off with string datatype, to keep it simple. Slot ID can be something.. maybe a unique identifier with string and int combination. Current parameter count is precise to my understanding. For a slot, slot name or id has to be there. product name is imp to add the product. Product quantity can be taken out as a constant, but that will a sort of limitation.

Other possible scenario is to add a slot with just the name. then in the next phase, we add the product and its quantity. Like we initialize a vending machine with certain number of slots : slot1, slot2, slot3 etc. and when the vendor is adding the products, he needs to fetch which slot he is adding to and enter the product name and quantity.

[Junilu Lacar]

I think you may be getting a hang of the process already. Here are the points I wanted to emphasize:

1. Start with knowing what behaviors you want from the software and state these as "stories"

2. Concentrate on defining a good API first. Delay decisions about implementation details for as long as you possibly can. This may seem to contradict the earlier motivation to choose a story based on its architectural significance but it's not really. It's kind of hard to delay architecturally significant decisions for very long because one definition of architecture is "something that's difficult to change later". The trick is figuring out which decisions are architecturally significant vs decisions that involve implementation details that can be easily changed.

3. Use tests to drive design thinking. Don't just write tests because you can.

4. Focus on simplicity and clarity first. Don't think about performance until you have something that works and is easy to maintain. Premature optimization is the root of all evil.

5. Follow the TDD Cycle (RED-GREEN-REFACTOR) as much as you can. Keep Uncle Bob's Three Rules of TDD in mind.

6. Involve other developers as much as you can. Solo development often leads to code that only that one developer can understand and maintain.

7. Involve system testers as much as you can, as early as you can as well. They can provide valuable input about the testability of the designs that you come up with.

Do you still want to continue with the exercise?

[s ravi chandran]

Junilu Lacar wrote:I think you may be getting a hang of the process already. Here are the points I wanted to emphasize:

1. Start with knowing what behaviors you want from the software and state these as "stories"

2. Concentrate on defining a good API first. Delay decisions about implementation details for as long as you possibly can. This may seem to contradict the earlier motivation to choose a story based on its architectural significance but it's not really. It's kind of hard to delay architecturally significant decisions for very long because one definition of architecture is "something that's difficult to change later". The trick is figuring out which decisions are architecturally significant vs decisions that involve implementation details that can be easily changed.

3. Use tests to drive design thinking. Don't just write tests because you can.

4. Focus on simplicity and clarity first. Don't think about performance until you have something that works and is easy to maintain. Premature optimization is the root of all evil.

5. Follow the TDD Cycle (RED-GREEN-REFACTOR) as much as you can. Keep Uncle Bob's Three Rules of TDD in mind.

6. Involve other developers as much as you can. Solo development often leads to code that only that one developer can understand and maintain.

7. Involve system testers as much as you can, as early as you can as well. They can provide valuable input about the testability of the designs that you come up with.

Do you still want to continue with the exercise?

Yes, very much..

[Junilu Lacar]

s ravi chandran wrote:Other possible scenario is to add a slot with just the name. then in the next phase, we add the product and its quantity. Like we initialize a vending machine with certain number of slots : slot1, slot2, slot3 etc. and when the vendor is adding the products, he needs to fetch which slot he is adding to and enter the product name and quantity.

Very well, we shall continue...

Your idea of initializing the vending machine makes sense. Why do we need slot names anyway? Shouldn't the number of slots be a pre-determined thing? A real-world vending machine is manufactured with a fixed number of slots so likewise, we could just set the number of slots when we instantiate our VendingMachine. Yes, I think I can go with that.

We can use a constant or a constructor parameter to specify this number. I like the idea of a constructor parameter to give a little bit more flexibility, so we would have code like this:
VendingMachine popMachine = new VendingMachine(20); // 20 slots available VendingMachine snackMachine = new VendingMachine(16); // 16 slots available
What if we fix the number of slots per row to something like four? Then we can just specify number of rows and have code like this instead:
VendingMachine popMachine = new VendingMachine(5); // 5 x 4 = 20 slots available VendingMachine snackMachine = new VendingMachine(4); // 4 x 4 = 16 slots available
Notice how the meaning of the constructor parameter is different for each option and thus, the appropriate name for the parameter will be different:
/** * Creates a vending machine with the specified number of * slots available. * * @param slotCount the number of slots this machine will have available */ public VendingMachine(int slotCount) {...} versus
/** * Creates a vending machine with the specified number of * rows of slots. The number of slots per row is fixed and * defined by the SLOTS_PER_ROW constant. * * @param rows the number of rows of slots this machine will have. */ public VendingMachine(int rows) {...}
So as you see, some of the questions that I asked have elicited a few options for the API design. These would likely have not come out otherwise had you just been solo programming. This underscores the importance of the conversations that come out of TDD. It also shows that you need to think about available options rather than just come up with an idea for a design and then run with it while assuming it's the best way to go. Just because you thought it was a good idea at first doesn't mean it actually is the best way to go. As it turns out, the add method wasn't even the best place to start developing the API design.

Here's a few more things about design:

1. Software should be soft. Your designs should be easy to change as you learn more about what the software wants to do.

2. There are no sacred cows. Don't be afraid to challenge or throw away a design option. Don't be afraid to explore other options after you've tried something.

3. The first design idea you have is often not the best one. Focusing on the API design first helps you keep your options open.

4. Discussing design options by yourself is difficult. Having other people to offer different perspectives makes it easier to find various design options.

[s ravi chandran]

Okay, I got the point for the constructor. But now how are we approaching the design? We leave the add method, so, the testability for vending machine will be different now, right?

[Junilu Lacar]

Here's another thought to consider: Software is not just about what's in the computer. Your brain is software, too. In fact, you, the developer, are the most important software component of all. It's your thoughts and ideas that get translated into something that the computer can do. To me, this is the "magic" of software development.

Poorly written programs reflect a poorly organized brain and thought process. Well-written and well-factored programs reflect the kind of thinking that went into creating them.

[Junilu Lacar]

s ravi chandran wrote:so, the testability for vending machine will be different now, right?

Yes. We backtrack and start over. Luckily, we have only written a few lines of code and throwing it away is not as painful.

How about you give it a shot. What test would you write to show that we don't have any constructor that does what we have just decided to do?

[s ravi chandran]

Junilu Lacar wrote:

s ravi chandran wrote:so, the testability for vending machine will be different now, right?

Yes. We backtrack and start over. Luckily, we have only written a few lines of code and throwing it away is not as painful.

How about you give it a shot. What test would you write to show that we don't have any constructor that does what we have just decided to do?

Well, adding the lines

VendingMachine popMachine = new VendingMachine(5);

itself will give the error. To fix that we add the next line

public VendingMachine(int rows) {
		// TODO Auto-generated constructor stub
	} 

[Junilu Lacar]

That's good. You're getting into the discipline of writing a few lines of code at a time and starting from the test code.

What assertion would you write then so that we have a failing test?

@Test 
public void should_instantiate_with_number_of_rows() {
    VendingMachine popMachine = new VendingMachine(5);
    assert... // what can we do here to make this test fail?
}

[s ravi chandran]

will it be a good concept to first create a skeleton structure for vending machine and then following the user stories we created? from functionality point of view, i think we can again start from add method.

[Junilu Lacar]

s ravi chandran wrote:will it be a good concept to first create a skeleton structure for vending machine and then following the user stories we created? from functionality point of view, i think we can again start from add method.

That's exactly what we're doing. We are framing out the API. Our discussion has led us away from the add method for now and to the constructor. We should follow through with this. This is another thing about development. You need to FOCUS. You have to resist the compulsion to follow every little thought that pops into your head before you finish one thing. When you say "create a skeleton structure" I imagine you thinking of a bunch of different methods that you think you'll need. Fight that urge. Always start from the tests and always focus on one or two things at a time. I say one or two since it's difficult to isolate everything. There's often another aspect of the design that you have to consider while you're focusing on one thing.

You didn't answer my question about the assertion we should make after instantiating a VendingMachine. How about this test then:

@Test   
public void should_instantiate_with_number_of_rows() {  
    VendingMachine popMachine = new VendingMachine(5);  
    assertThat(popMachine.isEmpty(0, 0), is(true));
} 

And we'd have this in the production code:

    /**
     * Checks if the slot in the specified row and column
     * is empty.
     *
     * @return true if the specified slot is empty; false otherwise.
     */
    public boolean isEmpty(int row, int col) {
        return false;
    }

This results in a failing test. What little bit of code can we write to make the test pass?

[Junilu Lacar]

Junilu Lacar wrote:You have to resist the compulsion to follow every little thought that pops into your head before you finish one thing.

You might ask, "Isn't that kind of what we did with the add method? Didn't we abandon that halfway?"

Well, yes and no. We followed through with at least one RED-GREEN-REFACTOR cycle. In a way, we did get it working, except we only got it working for one specific case. Then we got back to discussing the API again and whether or not the design choice we made was good. We backtracked on our choice and said we'd change the API and initialize the number of slots from the constructor instead. This is still architecturally significant since the way you reference slots will determine how the rest of the vending machine functionality will evolve. We need to follow through with this idea for initializing the vending machine slots until we can either commit to doing it this way or decide to go another route after more discussion and experimentation with tests.

[s ravi chandran]

Junilu Lacar wrote:

s ravi chandran wrote:will it be a good concept to first create a skeleton structure for vending machine and then following the user stories we created? from functionality point of view, i think we can again start from add method.

That's exactly what we're doing. We are framing out the API. Our discussion has led us away from the add method for now and to the constructor. We should follow through with this. This is another thing about development. You need to FOCUS. You have to resist the compulsion to follow every little thought that pops into your head before you finish one thing. When you say "create a skeleton structure" I imagine you thinking of a bunch of different methods that you think you'll need. Fight that urge. Always start from the tests and always focus on one or two things at a time. I say one or two since it's difficult to isolate everything. There's often another aspect of the design that you have to consider while you're focusing on one thing.

You didn't answer my question about the assertion we should make after instantiating a VendingMachine. How about this test then:

@Test   
public void should_instantiate_with_number_of_rows() {  
    VendingMachine popMachine = new VendingMachine(5);  
    assertThat(popMachine.isEmpty(0, 0), is(true));
} 

And we'd have this in the production code:

    /**
     * Checks if the slot in the specified row and column
     * is empty.
     *
     * @return true if the specified slot is empty; false otherwise.
     */
    public boolean isEmpty(int row, int col) {
        return false;
    }

This results in a failing test. What little bit of code can we write to make the test pass?

Ok, so we are working on the skeletal structure. Well, if we are going to validate the slot count, we can consider the assumption that number of slots are some constant value ( we took 4 slots if I remember) , in that case we can reduce the check to just the row count. Also, we can hardcode the value as true, similiar to what you had shown for the itemcount.

like

public boolean isEmpty(int row) {
        return true;
    }

[Junilu Lacar]

Again, I want to call your attention to the fact that we only have a few lines of code but we have had a lot of discussion about our options. You have also picked up on a lot of things about TDD that you didn't know when we first started. In real-time, with you and me sitting in front of a computer, this whole conversation would have happened in the span of a few minutes. This is what you don't get from reading books about TDD.

Aside from the threads in these forums where I have done the same thing, one of the few examples I've seen that simulates the experience you get with TDD is this article: http://www.objectmentor.com/resources/articles/xpepisode.htm . Read through that and try to get a feel for the dynamics of the conversation. I've tried the same exercise with other people many times and it never goes the same each time. About the only things that stay true are the need for focus on the API first, following the rules of TDD, and lots of discussion.

[s ravi chandran]

Junilu Lacar wrote:Again, I want to call your attention to the fact that we only have a few lines of code but we have had a lot of discussion about our options. You have also picked up on a lot of things about TDD that you didn't know when we first started. In real-time, with you and me sitting in front of a computer, this whole conversation would have happened in the span of a few minutes. This is what you don't get from reading books about TDD.

Aside from the threads in these forums where I have done the same thing, one of the few examples I've seen that simulates the experience you get with TDD is this article: http://www.objectmentor.com/resources/articles/xpepisode.htm . Read through that and try to get a feel for the dynamics of the conversation. I've tried the same exercise with other people many times and it never goes the same each time. About the only things that stay true are the need for focus on the API first, following the rules of TDD, and lots of discussion.

Okay, I read it half. It's way too lengthy. Will complete it later. I did get the concept though.. We have to look for tests and dependencies and then move forward.

[Junilu Lacar]

But how does checking if a row is empty help us later? It seems more logical to check if a particular slot is empty. Do you think it's easier to address slots by a single number then? That's not a bad idea. It's a plausible alternative to a row/column addressing scheme. If we go with just one parameter, I would say the number should represent a slot number, not a row.

/**
 * Checks if the specified slot in this vending machine is empty.
 * Slots are numbered from 0 - N, where N is equal to 
 * (SLOTS_PER_ROW * number of rows) - 1.
 * 
 * @return true if the specified slot is empty, false otherwise.
 */
public boolean isEmpty(int slot) {...}

[Junilu Lacar]

Notice how the change in one name, row to slot, changes the semantics of the API dramatically. It's basically the same exact code but the semantics are very different. This is what a lot of developers take a long time to learn. Many developers will not go back and examine a name carefully to see if it fits the semantics of the API. They just go with whatever comes to mind and leave it at that. It's important to think about what you're writing and what it's supposed to mean to others when they read the code but sadly, many developers don't put enough thought or care into choosing good names to use in their programs.

[s ravi chandran]

Okay, but will this change the objective of isEmpty()? Now we are considering that we will give a slot number to check if it is empty or not. So, if there are 20 slots, we will have to give 20 calls to check each. The reason I was considering reducing the parameter was that slots per row was a constant value, so it will not be empty. if we imagine the slot combination as a 2 dimensional array, even with the column size being fix, we need to address each slot with both the indexes of row and column. can we reduce that? how about we have a fix iteration of slot_per_rows and if any of the slot is filled, we return false; like

public boolean isEmpty(int row) {

for( int slotPosition = 0; slotPosition< slots_per_row; slotPosition++)
   {
               // if slotposition is filled
               // return false
   }

// else return true;

} 

This is not a code statement, I am just giving the hypothetical case.

Edit: i was returning the wrong value in the condition

[Junilu Lacar]

But why do you need to check for an empty row? What's the point? I can see that checking for an empty slot is useful because you don't want to let a customer choose a slot that has no product in it. Like when you ask them "What slot number is the product that you want in?" When in the buying process will you need to ask them "What row do you want?" I don't see what value you get by checking if a row is empty.

[Junilu Lacar]

And why would we need to check if all slots are empty in one go? What is the use case for checking all slots at one time? There's no story for that

[Junilu Lacar]

So you need to go back to the tests to elaborate on the story.

@Test
public void should_have_empty_slots_when_instantiated() {
    VendingMachine popMachine = new VendingMachine(1); // 1 row = 4 slots
    assertThat(popMachine.isEmpty(0), is(true));  // first slot is empty
    assertThat(popMachine.isEmpty(3), is(true));  // last slot is empty
}

Then, I'd go back to the add method and verify that a slot is not empty when I add a product to it

@Test
public void slot_should_not_be_empty_when_product_has_been_added() {
    VendingMachine popMachine = new VendingMachine(1); // 1 row = 4 slots
    popMachine.add(1, 5);
    assertThat(popMachine.isEmpty(1), is(false));
}

// in VendingMachine.java:
public void add(int slot, int quantity) {
}

public boolean isEmpty(int slot) {
    return true;
}

Running all tests, the previous constructor test still passes but the new test will fail. This proves that we have a bug. Then we try to fix that bug. How do you think we should do that?

[Junilu Lacar]

Now we get to think about implementation details in VendingMachine. I'm going to try using a simple array first.

public class VendingMachine {
      private int[] slots;

      public VendingMachine(int rowCount) {
            slots = new int[rowCount * 4];
      }

      public boolean isEmpty(int slot) {
            return slots[slot] == 0;
      }

      public void add(int slot, int quantity) {
            slots[slot] += quantity;
      }
}

This makes all the tests pass. We still have written a very minimal amount of production code. We then go to the refactoring step. We see the magic number 4. We create a constant for that and get this:

public class VendingMachine {
      public static final int SLOTS_PER_ROW = 4;

      private int[] slots;

      public VendingMachine(int rowCount) {
            slots = new int[rowCount * SLOTS_PER_ROW];
      }

      public boolean isEmpty(int slot) {
            return slots[slot] == 0;
      }

      public void add(int slot, int quantity) {
            slots[slot] += quantity;
      }
}

We run all tests again and the tests still pass.

Now, we ask "What's the next test we can write to show we still have bugs?"

[s ravi chandran]

Okay, what I wanted to check with isEmpty() for a row is that the vendor might use this to see which slot row is empty, so that he can add more products to it. assuming that he will add more products only when the whole row is empty. i guess customer side is better use case, in that sense, we should be checking each slot.

Coming back to the code, the signature of add()

public void add(int slot, int quantity) {  
} 

will change right? I can understand that for minimum changes to the code, we are using int array and hence, product name should not be added at this moment. I did not get this line:

slots[slot] += quantity; 

does this mean, products can be added at any moment, and not when the whole row is empty?

[Junilu Lacar]

s ravi chandran wrote:does this mean, products can be added at any moment, and not when the whole row is empty?

Yes. I don't see any reason why the guy, on seeing that there's only a couple of product left in a slot, wouldn't just go ahead and top it up. Why wait until the slot is empty? What if you're selling Coke, Cherry Coke, Diet Coke, and Mountain Dew on the same row? You'd think that one of those products is going to be less popular than others. If you ran out of Coke, do you have to wait until all the rest of the products are sold out before you fill all the slots in that row up again? That doesn't make sense.

[s ravi chandran]

about the next possible bug, I will say we are still working on add(), so, two things I see should be present there. One is each successful add should return true and each time the quantity should not exceed 4, as our max slot is 4.

public void add(int slot, int quantity) {  

            if(!quantity>4)
               {
                  slots[slot] += quantity;  
                 }
            } 

[s ravi chandran]

or rather the summation of slots[slot] + quantity should be less than slots_per_row.

	public boolean add(int slot, int quantity) {
		
		int slotQuantity = slots[slot];
		
		if( slotQuantity+ quantity > SLOTS_PER_ROW)
		{
			return false;			
		}
		else
		{
			slots[slot] += quantity;
			return true;
		}
	} 

@Test
	public void quantity_should_not_exceed_max_slots_per_row_when_product_added()
	{
		VendingMachine popMachine = new VendingMachine(1); // 1 row = 4 slots  
	    assertThat(popMachine.add(1, 4), is(true));
	    assertThat(popMachine.add(1, 1), is(true));
	}

how does this look?

[Junilu Lacar]

If we were programming side by side, I would sternly remind you not to mess up the formatting of the code. Keeping the code clean also entails keeping it well formatted. Don't mess with my formatting.

Also, why did you just re-introduce the magic number 4? We already extracted a constant for that. Besides, 4 is not the maximum amount of product per slot. It's the number of slots in one row in the vending machine. Maybe we need to change the terminology a little bit.

A vending machine can have multiple shelves (singular shelf)
Each shelf can have up to 4 trays
Each tray should be filled with only one type of product
Each tray can hold up to 8 items of product

Does that make sense?

[Junilu Lacar]

Ok, ignore the parts of my last reply that were made irrelevant with your last post. I still don't see a need to return a boolean from the add method.

[s ravi chandran]

Junilu Lacar wrote:Ok, ignore the parts of my last reply that were made irrelevant with your last post. I still don't see a need to return a boolean from the add method.

well, the boolean was to notify the quantity exceed case. I do not know its practical value.

[Junilu Lacar]

In what scenario would add return false then? What if you try to add more items to a tray than it can hold. Like if you had 5 items and you tried to add 5 more items. If the maximum items per tray is only 8, then what happens? Return true still? That doesn't sound right to me.

[s ravi chandran]

Junilu Lacar wrote:In what scenario would add return false then? What if you try to add more items to a tray than it can hold. Like if you had 5 items and you tried to add 5 more items. If the maximum items per tray is only 8, then what happens? Return true still? That doesn't sound right to me.

Okay, i need to understand this for now.

A vending machine can have multiple shelves (singular shelf)
Each shelf can have up to 4 trays
Each tray should be filled with only one type of product
Each tray can hold up to 8 items of product

row and column was looking easier. :-) The logic I was trying was to tell the vendor that quantity limit has reached and more items can not be added. sounds reasonable?

[s ravi chandran]

we do need a boundary condition right? if we bring multiple products in each tray, then we will need a constant value for that also like

MAX_PRODUCTS_PER_SLOT

I believe add() doesnt support this yet.

[Junilu Lacar]

And what would the client code look like? How does the true/false value coming out of the add method become useful to something else? If it's not useful, why return it?

If I were to think holistically, I would imagine a guy coming in to fill up the vending machine. He has containers of products, let's call this his "Stock". He would also want to track the change in quantity in his Stock as he fills up the VendingMachine from it. Then, an integer return value would be more useful:

     int stockCount = 50;  // I have 50 in my stock crate
     stockCount -= popMachine.topUp(0);

My thinking is that the vendor will always want to top up (or fill up, if you prefer) a slot that is empty or partially empty. Having a fillUp or topUp method return the quantity needed to fill a tray back up to full capacity is more useful. Then the tests would change again.

@Test
public void topUp_should_fill_an_empty_tray_to_capacity() {
     VendingMachine popMachine = new VendingMachine(1);
     int stockCount = 10;
     stockCount -= popMachine.topUp(0); // fill up tray 0
     assertThat(stockCount, is(2));
}

@Test
public void topUp_should_fill_a_partially_empty_tray() {
     ... // how do we make a partially empty tray?
}

[Junilu Lacar]

s ravi chandran wrote:row and column was looking easier. :-) The logic I was trying was to tell the vendor that quantity limit has reached and more items can not be added. sounds reasonable?

I still don't see the usefulness of a boolean. Also, you want to use terminology that's closer to what the vendor uses. row and column are names that programmers understand but shelf, tray, and product item are things that a vendor is more likely to understand. Programs that use names that reflect the terminology used in the problem domain are easier to understand and maintain.

[Junilu Lacar]

If you have trouble understanding the story in that test, here's a more explicit story:

@Test  
public void topUp_should_fill_an_empty_tray_to_capacity() {  
     VendingMachine popMachine = new VendingMachine(1);  
     int stockCount = 10;  
     int itemsAddedToMachine = popMachine.topUp(0); // fill up tray 0  
     assertThat(stockCount - itemsAddedToMachine, is(2));  
}  

That is, the topUp method returns the number of items that are needed to fill up the specified tray. You then take that number and subtract it from what you had in stock and you would get the quantity left in stock after you filled up the tray in the vending machine to capacity.

You start with an empty tray (with 8 products maximum capacity). You have 10 items in your stock crate. You fill up the empty tray, i.e. you top it up with products taken from you stock crate, that leaves you with 2 products in you stock crate and a full tray in the vending machine.

[s ravi chandran]

Junilu Lacar wrote:

s ravi chandran wrote:row and column was looking easier. :-) The logic I was trying was to tell the vendor that quantity limit has reached and more items can not be added. sounds reasonable?

I still don't see the usefulness of a boolean. Also, you want to use terminology that's closer to what the vendor uses. row and column are names that programmers understand but shelf, tray, and product item are things that a vendor is more likely to understand. Programs that use names that reflect the terminology used in the problem domain are easier to understand and maintain.

I mean't in terms of understanding myself. multiple rows and 4 columns of product looked easier for me to visualize.

I added these lines in my code

 public static final int MAX_PRODUCTS_PER_SLOT = 8;

public int topUp(int slot) {
		return MAX_PRODUCTS_PER_SLOT;
	}