aspose file tools*
The moose likes Beginning Java and the fly likes Scope Creep Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Scope Creep" Watch "Scope Creep" New topic
Author

Scope Creep

Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8207
    
  23

Junilu Lacar wrote:To be most helpful to the OP, I think we need to stick with the core requirements as he gave them and not introduce scope creep by speculating on other scenarios or extensions to the requirements.

Hmmm. Not sure I agree with that; although I understand the warning about scope creep.

By that measure, you should simply return 0 from a hashCode() method unless you're specifically told that it must be "good".

Good design is good design, and I think it's worth learning as early as possible; and cardinality is a basic tenet of modelling.

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5018
    
    8

One thing that I've learned from coaching my teammates on TDD and my daughter in volleyball is that it's best not to overwhelm and confuse them with too many different things at once. A few things at a time that they can focus on getting better at usually gets better results and helps build up their confidence.


Junilu - [How to Ask Questions] [How to Answer Questions]
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8207
    
  23

Junilu Lacar wrote:One thing that I've learned from coaching my teammates on TDD and my daughter in volleyball is that it's best not to overwhelm and confuse them with too many different things at once. A few things at a time that they can focus on getting better at usually gets better results and helps build up their confidence.

Fair enough; but from what I can gather, most of the "speculation" here has revolved around Raymond's assumption that he has to somehow push and pop the "busy" counter off the stack, when that was plainly not part of the instructions.

OK, you could have a BusyCounterForPersonAtTheFront and stick it in the Queue; it makes no real difference to the outcome. I just reckon that having a Cashier (or whatever) that incorporates that counter, rather than slavishly following instructions, is a better model.

Winston
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5018
    
    8

And therein lies the rub.

The OP simply wanted to know how to update the head element of the Queue, per his instructions. He never mentioned the idea of push/pop (Fred's suggestion) or Cashier (Winston) or BusyCounter (Winston) or multiple Cashiers or Customers leaving before they get to the head of the Queue.

We may be going overboard with trying to get the OP to solve the problem himself so it might be more helpful to give him concrete advice directly targeting his requirements, not our interpretations or speculation.

If I were to summarize:

* The OP's requirements mention a Customer that will be put on the Queue, therefore, the OP should define a Customer class that has these responsibilities:
1. internally initialize a random number to represent their "processing time"; think of it as "number of items to process" if you like
2. decrement that number

* Setup a loop for the required number of iterations

* Write a method that calculates whether or not a new Customer should be added to the Queue (25% chance); this method is called on each iteration

The OP should note that using an Integer as the element in his Queue is not going to meet his requirements.

Here's a counterpoint for the need to have a Cashier: who's to say that the original requirements weren't meant to simulate a queue for an automated kiosk in a store, e.g. RedBox kiosk? Either way, I feel there is no compelling reason to add anything more than what's explicitly stated in the OP's requirements.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8207
    
  23

Junilu Lacar wrote:The OP simply wanted to know how to update the head element of the Queue, per his instructions. He never mentioned the idea of push/pop (Fred's suggestion)...

Actually, he did indirectly:
"Once something is added, I need to then update the top object each time the loop runs by decrementing by one. Once the object become zero, I will then remove that object."
and that was his interpretation of the instructions he was given - which I still believe to be incorrect.

He further said that he was using an integer, which Fred reasonably assumed meant an Integer as opposed to a method.

...or Cashier (Winston) or BusyCounter (Winston) or multiple Cashiers or Customers leaving before they get to the head of the Queue.

The first two are admittedly down to me, but the last one isn't. All I was saying is that it makes sense to have a model that doesn't care whether there are one or more queues, or one or more Customers being serviced at a time.

We may be going overboard with trying to get the OP to solve the problem himself so it might be more helpful to give him concrete advice directly targeting his requirements, not our interpretations or speculation.

And here's where we disagree. I don't think that anyone has ventured too far into "speculation", save to try and divine exactly what OP was asked to do, and point out some problems with his current thinking.

And if you don't mind, I'll critique your analysis:
1. Your idea of a Customer that keeps track of how long they have to wait is favouring inheritance over composition:
If you're going to make the Customer responsible for keeping track (a major flaw in the requirements, IMO), why not just hand him a Stopwatch initialized with the correct wait time?
2. Your solution (and the requirements, which have no business mandating it) require that every Customer joins the queue, whether they need to or not.

Slavish adherence to requirements result in things like hashCode() methods that return 0 - perfectly legal and guaranteed to work for any test that doesn't see time as a major factor, but entirely contrary to the intent of the method. And that, to me, is not design.

Here's a counterpoint for the need to have a Cashier: who's to say that the original requirements weren't meant to simulate a queue for an automated kiosk in a store, e.g. RedBox kiosk? Either way, I feel there is no compelling reason to add anything more than what's explicitly stated in the OP's requirements.

I'm not sure I see the distinction (but maybe I'm just being thick). My "Cashier" was simply a name for a service point, be it a real cashier, a till, an ATM, a car wash, or a RedBox kiosk. To me, the whole point is that it's how long that service point is busy that determines Customer flow.

Winston
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5018
    
    8

I think you have fallen into the "overthinking" trap that you tried to warn the OP against. He had one post where he stated his requirements pretty clearly.

Raymond Gillespie wrote:
Below is my instructions.

How many minutes it takes to process the customer. This should initialized by generating a random number between 1-5. (Use Random class).

The program should simulate 60 minutes of activity at the store. Each iteration of your program should represent one minute. At each iteration (minute), your program should do the following:

Check to see if new customers are added to the queue. There is a 25% chance that new customers show up (need to be added to the queue) every minute.

Update the customer object currently being serviced (if one exists). This will be the customer object at the front of the queue. If the customer has been completely serviced, remove them from the queue


I don't think that sticking to the requirements rather than unnecessarily embellishing on them is being "slavish" at all. It's a school assignment with a specific learning goal so in this case, I think sticking to what's explicitly asked for will give the OP a better chance at a good grade. And even if it were for work, I still would stick with the known requirements and let conversations with the user, not speculation by the developers, flush out additional requirements.

As for the critique,
1) I don't see where inheritance over composition comes into play. If the Customer creates/holds/initializes the number, that's actually composition, not inheritance.
2) Trapped by real-world modeling again. I view the program as a queue simulation. Customers who do not join the queue are out of scope of the problem. Whether there are Customers who don't need to join the queue is irrelevant. The requirements are that there is a 25% chance that a Customer will join the queue on each iteration. This is not a brain-teaser or something that needs deep philosophical debate. It's a straightforward constraint.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8207
    
  23

Junilu Lacar wrote:Trapped by real-world modeling again. I view the program as a queue simulation. Customers who do not join the queue are out of scope of the problem. Whether there are Customers who don't need to join the queue is irrelevant.

Ah well, I guess we'll have to agree to disagree on this one.

Quite apart from the fact that the requirements are telling OP how to solve the problem (and IMO, badly); if the problem is simply a queue simulation, then why mention a "store"?

Either there is some context with the real world or there isn't. Personally, I like to use all the information I'm given and make my own choices (as you plainly did when you mentioned the difference between a queue and a Queue ).

Winston
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5018
    
    8

I won't disagree with you that the problem might be presented differently, perhaps in a way that would open the door to more critical/creative thinking. However, I would not presume to judge the problem just on face value. As I said, this is obviously for classroom instruction and the instructor may simply have wanted to target specific learning objectives by giving this problem. There is certainly merit in considering the concept of "point of service" to encapsulate certain behaviors and maybe bring the simulation closer to the real world. I just felt that by bringing all these other considerations to bear without express mention by the OP, we were potentially confusing a beginner more than he already was. We probably should just ask him if his instructor is the type to give effort points for thinking outside the box or a stickler for following instructions.

Cheers
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8207
    
  23

Junilu Lacar wrote:We probably should just ask him if his instructor is the type to give effort points for thinking outside the box or a stickler for following instructions.

Now there, I completely agree.

I also think that the instruction that caused all the confusion (which we weren't given until quite a way into the thread) was:
"Update the customer object currently being serviced (if one exists). This will be the customer object at the front of the queue. If the customer has been completely serviced, remove them from the queue."

That first sentence is very badly written because it's telling OP how to code his solution. Since there can only be 1 person (at most) at the front of a queue, it really doesn't matter logically whether whether the timer is connected with the "person at the front" or the queue itself; and his original question - and the source of his confusion (and ours) - was "[How do I] Modify the first element in a queue?".

I will concede that my suggestion of a service point was extrapolation; but it was based on his first description of the problem, not the actual instructions.

Ain't design fun?

Winston
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Scope Creep