• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

implement vending application

 
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok. Is this the kind of test code you had in mind with the change to the add API?
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let's see if refactoring this is better:

What do you think?
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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

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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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:

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:

Notice how the meaning of the constructor parameter is different for each option and thus, the appropriate name for the parameter will be different:
versus

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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
itself will give the error. To fix that we add the next line
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
s ravi chandran
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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:

And we'd have this in the production code:

This results in a failing test. What little bit of code can we write to make the test pass?
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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:

And we'd have this in the production code:

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
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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


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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So you need to go back to the tests to elaborate on the story.

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

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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now we get to think about implementation details in VendingMachine. I'm going to try using a simple array first.

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:

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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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()
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: does this mean, products can be added at any moment, and not when the whole row is empty?
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
s ravi chandran
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
or rather the summation of slots[slot] + quantity should be less than slots_per_row.





how does this look?
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 I believe add() doesnt support this yet.
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

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.
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have trouble understanding the story in that test, here's a more explicit story:

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
Ranch Hand
Posts: 590
6
jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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


 
Wink, wink, nudge, nudge, say no more, it's a tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic