• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

[Split] Designing a better parking lot

 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(NOTE: This topic was split off from here: https://coderanch.com/t/628047/patterns/Parking-Lot-Design)

Why not just start with something simple? Here's a scenario that I can take from the parking garage at one of the malls in our area. This is a self-parking facility that has LED signs at the entrance to show how many spots are available. Above each spot in the garage is a sensor that can sense whether or not there is a vehicle in the spot. If the spot is open, a green light above the spot will be activated. This helps customers find open spots. This also helps the system update the sign at the entrance to show how many open spots there are in the garage.

You will need to account for vehicles that have entered the garage but are still looking for an open parking spot. During that time, there will be open spots but there may not be any more spots available for additional vehicles that haven't entered the garage yet. There are entry and exit gates that can be monitored by the system. The system should be smart enough to inform potential customers whether or not there are still spots that will be open after they enter the garage and everyone else who entered before them has parked. It would be particularly annoying for a customer if they entered earlier but couldn't find the open spot and had it taken by someone who came in later. Maybe there should be signs inside the garage that help customers find where the open spots are as well. I think the system at the local mall actually has that kind of thing.

Edit: Let's say the garage is divided into four sections: A, B, C, and D sections. Assume for now it's a 1-level garage. There are strategically placed signs inside the garage that help customers see how many open spots there are in each section. Customers then pick a section and head there to find a green light. As customers take up spots, the green lights go off and the information about the number of spots available in that section is updated. Likewise, when a customer leaves a spot, the green lights turn on and the signs get updated as well. This is in contrast to the signs outside the garage entrance showing how many spots are available. These are updated when the entry/exit gates open/close to let vehicles enter/exit the garage.

This seems like a relatively simple thing to design and implement. Start with this.
 
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I still haven't coded anything yet, but I thought it was interesting that I automatically started thinking (falling for the trap) of what objects do I have and what can they do and what attributes they have, but Instead this time I tried to tackle this from addressing the problems point of view.

This is a self-parking facility


I'm not sure if I'm being over analytical here, as I'm not sure if this qualifies as a problem, but I did ask myself is this significant at all for this design? who is responsible for parking is it the car or the garage itself ie where is the park() located? nevertheless, it led me to this Problem : choose which spot to park a car in if there is any available at a given time. which led to another Problem : how to ensure that no car gets in only to find all spot are taken. to which the solution is the LED sign at the entrance.

LED signs at the entrance to show how many spots are available.


Problem : how to find out if the Garage has available spots and how many? it is achieved by keeping track of the numbers of cars inside the garage, parked or not , at the moment VS total number of slots . where:
a- the number of cars ++ as soon as a car gets in and not necessarily parked yet
b- the number of cars -- only once the car exits garage.


Above each spot in the garage is a sensor that can sense whether or not there is a vehicle in the spot. If the spot is open, a green light above the spot will be activated. This helps customers find open spots. This also helps the system update the sign at the entrance to show how many open spots there are in the garage.


at first I thought, isn't it enough to have the garage tell you the number of spots available? do I really need to have this especially that the outer LED sign is in no way related to any spot's state,occupied or not, but merely dependent on number of cars. then I just realize that this along with the inner LED sign, address a diffrent problem than the outer one, which was to answer the question "if I get in will I find a spot to park?", and now its asnwering the problem: where is an available spot located and how to find it easier and quicker. and having the Garage divided in into four sections: A, B, C, and D sections. serves to make this easier and more efficient coding wise.


so far these are the main problems that i identified, and I want to ask you
1- am thinking in the right direction?
2- did I miss a major problem?
3- throughout this excesise, I did struggle with the "who does what to whom" pattern of thinking. which is to say who's responsibility is it which boils down to where this Method() should be located, for example when you said " facility that has LED signs at the entrance to show how many spots are available." I asked to who is it showing this to? is it for cars to know "can I go inside" or for the Garage to know" can I let more cars in"
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Raed, thanks for all that. It's very interesting and informative to understand other people's thought processes and what you shared has given me a lot of insight into your thought process.

Now, allow me to share mine.

As I said, I usually start by coming up with a high-level picture, then think about major user-system interactions, and then think about test, then about the objects involved, in that specific order.

The high-level picture
I'm going to need:
1. Something to monitor the entering and exiting of vehicles
2. Something to monitor the using up and freeing up of parking spots
3. Something to control external signs (?)
4. Something to control internal signs (?)

User-System interactions
Mostly passive:
1. @Entry/Exit gates
2. @Parking Spot sensor
3. Prior to entry - customer looks at external sign(s)
4. Post entry - customer looks at internal sign(s)

Tests
1. Garage is completely empty
2. Garage is almost full, someone still needs to park
3. Garage is almost full, someone just parked in last open spot
4. Garage is full, someone attempts to use entry gate
5. Garage is full, has open spot, customer hasn't exited
6. Garage is full, has open spot, customer has exited

Candidate Objects
1. Spot - knows if occupied or not; broadcasts changes in state
2. Section - has Spots; observes Spots and broadcast collective state of Spots
3. Garage - has Sections; observes Sections and Entry/Exit gates; displays current state

Then I will start doing TDD.

 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Raed Tabani wrote:

This is a self-parking facility


I'm not sure if I'm being over analytical here, as I'm not sure if this qualifies as a problem, but I did ask myself is this significant at all for this design? who is responsible for parking is it the car or the garage itself ie where is the park() located? nevertheless, it led me to this Problem : choose which spot to park a car in if there is any available at a given time. which led to another Problem : how to ensure that no car gets in only to find all spot are taken. to which the solution is the LED sign at the entrance.


It seems to me that you're over-anthropomorphizing (assigning human-like qualities/behaviors to non-human things) here. Why should there even be a park() method somewhere? The point of stimulus to the system is a sensor that says whether or not a spot is occupied. If anything, there will be a setOccupied() method needed somewhere, which logically would be a Spot object. The system doesn't choose to park anything; it merely reacts to stimuli and updates its observed state. The actual drivers of the cars in the real world are the ones who choose the parking spots based on their being physically available in the real world, not the state as reflected in the system.

The question I would ask is "How does the system initialize itself to reflect the current state of the garage?"

I think of the following scenarios:
1. First starting up the system
2. Restarting the system after power failure
3. Refreshing the system after maintenance of components (sensors can be faulty and need replacement or recalibration)

Do you see how I keep it real and not go into an imaginary world of abstract objects and relationships? I probably did that kind of thing when I was learning about OO but I realized at some point just how much I was over-thinking it and that resulted in some interesting but bizarre and unnecessary complications. The KISS principle definitely applies here.

Ensuring that no customer enters only to find there are no available spots anymore is done at the entry/exit gates. The entry gate should not open until the system can determine that at least one vehicle has gone through the exit gate after a change in the number of open parking spots was detected. It should be fairly easy to calculate the total #vehicles in the garage, including those that have entered/not exited, vs the #open spots. At no time should the total # of vehicles in the garage be greater than the total # of spots. That's the simplest formula I can think of.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Raed Tabani wrote:I asked to who is it showing this to? is it for cars to know "can I go inside" or for the Garage to know" can I let more cars in"


Dangerously close to over-thinking it again.

There are no Car objects in this system. Cars are part of the external stimulus to the system. Cars will actuate the sensors when they pull in/pull out of a parking spot. The drivers of cars actuate the entry gate by pushing a button and taking a ticket to enter the garage. Likewise, the drivers actuate the exit gate by inserting their parking ticket and making a payment. Cars can be eliminated right away as candidate objects in the system because they have no role besides providing stimulus to the Sensors which are part of the system. You can eliminate Driver as well, in case you're thinking about maybe having that as an object, too.

There might be a Garage object that controls the entry/exit gates, so the answer to your question is the Garage(?) is responsible for controlling when more vehicles can get through the entry gate.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Raed Tabani wrote:having the Garage divided in into four sections: A, B, C, and D sections. serves to make this easier and more efficient coding wise.


That's not the primary purpose but it's a nice side-effect of a well-design physical system. I like parking in that garage at the mall because it helps me park faster. I don't have to drive around, straining to find an empty spot while watching out for pedestrians and other cars. I just look up and see which section has the most # of spots, head that way, then look for the green lights, which are a group of LED lights about 2-3 inches in diameter and easily visible from a distance. I doubt the creators of this system were thinking about ease/efficiency of programming when they came up with this design. I think the primary objective/consideration was intuitiveness and ease of use to the customer.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Raed Tabani wrote:, and I want to ask you
1- am thinking in the right direction?


I think you are definitely asking some good questions and expanding your perspective. That's always a good thing. Now that you know there are other venues of thought, it's up to you to explore and experiment. The most important thing is to not be afraid to make mistakes. Mistakes are a good, if not the best, way to learn and get better at something. A development practice like TDD has making mistakes practically built into it. That's why I like it a lot.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Raed Tabani wrote:keeping track of the numbers of cars inside the garage, parked or not , at the moment VS total number of slots . where:
a- the number of cars ++ as soon as a car gets in and not necessarily parked yet
b- the number of cars -- only once the car exits garage.


Good observation. In fact, it tells me that I was probably overthinking things before, too.

I wrote:Candidate Objects
..
3. Garage - has sections; observes Sections and Entry/Exit gates; displays current state


Based on your observation, Garage may not even be a valid candidate object. Maybe Gate? This will just monitor entries/exits. The state of the various Sections are not relevant to the Gate in fulfilling its responsibility. The Gate just needs to know how many total spots there are in the garage and can calculate available spots based on total_spots - entries + exits;

Decoupling the Gate from the Section could even improve the overall system design. We can get a sanity check by comparing Available reported by the Gate vs Available reported by all the Sections. If there is a discrepancy, there might be something wrong with either the gates or the sensors. This can help the folks who maintain and operate the garage detect and address any problems with these system components.
 
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think most important thing is clarity of problem and requirement. Say, if i follow what OP actually said in his first post then i could never come up with the cases
as Junilu mentioned. After reading the story as mentioned by Junilu, i could think from actual problem statement wise.

My thoughts are:

Should show available parking slot
should show occupied parking slot
should allow to enter the vehicle only when some other vehicle exist in case of only 1 parking slot available
should reduce the available spot once vehicle enters into the gate and up one available spot when vehicle leave its position
Should not allow to park any more vehicle till spot is available
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tushar Goel wrote:
Should show available parking slot
should show occupied parking slot
should allow to enter the vehicle only when some other vehicle exist in case of only 1 parking slot available
should reduce the available spot once vehicle enters into the gate and up one available spot when vehicle leave its position
Should not allow to park any more vehicle till spot is available


Ok, let's clarify some of these because they can be interpreted a few ways.

Let's start with the first two: Should show available/occupied parking spot. (Let's stick with "spot" instead of switching to "slot")

I'll clarify the first one with a Given-When-Then statement:


Is this what you had in mind, Tushar?
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As for showing # occupied, is that really necessary? The customers only care to see how many are available. Why would they care to see how many spots are occupied?
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tushar Goel wrote:should allow to enter the vehicle only when some other vehicle exist in case of only 1 parking slot available


As noted earlier, the Gate really only needs to know total spots in the garage and number of entries and exits. The Gate does not have to know anything about what's actually happening in the different sections or whether or not there are spots that have opened up.
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Is this what you had in mind, Tushar?



I am not thinking to show numbers. I am thinking like below:

SlotNumber L1 L2 ................. LN // here Lx represents the LED at the particular spot in particular section

So i think if the spot is occupied than LED will be RED else Green. something like this:

A G G G R R ..... // where A is section , G is the green and R is Red color

This will tell the users exactly which spot is available to park. Count increment as i mentioned earlier would be useful to manage this.
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

the Gate really only needs to know total spots in the garage and number of entries and exits.


Actually i was trying to think higher level. I am not considering who's responsible to do that or implementation detail. It was a point to my to do list. I will decide that once i write some tests.

Sorry if i think wrong.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tushar Goel wrote:

Is this what you had in mind, Tushar?


SlotNumber L1 L2 ................. LN // here Lx represents the LED at the particular spot in particular section

So i think if the spot is occupied than LED will be RED else Green. something like this:

A G G G R R ..... // where A is section , G is the green and R is Red color

This will tell the users exactly which spot is available to park. Count increment as i mentioned earlier would be useful to manage this.


I think that makes the customer work too hard -- there are just too many elements to decipher. With the Letter-Number, it's straightforward. The simplicity of the green light acting as a beacon to an open spot is also quite nice. Drivers just need to scan the row and look for that little green circle and drive towards it. No counting, no deciphering. Why would you need to install Red lights to indicate an occupied spot anyway? Customers are not interested in finding occupied spots, they're looking for OPEN spots. Why bombard them with additional stimuli that they're going to have to ignore anyway? Do you see what I mean?

Note that this system is not something that I just imagined: it's an actual system that is currently in place at a mall in my area. It works well, too. You see from the sign on the outside that there is room in the garage (general info), you drive in and see how many spots are open in each general area, which is more specific information to guide you. You then drive towards the area and look for the Green lights, the most specific info you need to get what you want, which is to park your car and go shopping. The system is simple and intuitive and people immediately get it even if they've never seen it before.

You could go ahead and do it your own way but then you'll be steering the conversation in many different directions and I don't think that's going to be very useful. How about we stick with what I've stated and you can help think of ways to implement a design that stays in the bounds of those parameters?
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Think about it from the equipment maker's and the garage management's point of view as well. If you have red lights on the sensors, that's another component that can fail. Plus the circuitry on the sensor will be more complicated. And having a Red light on when no light is just as informative drives up electricity consumption and the overall cost of running the system. Sure, LED lights are very economical and last a lot longer with practically zero maintenance but still, you'd drive the initial cost of the system much higher because instead of 100 LED lights, you need 200 LED lights. It's just not practical to have Red LED lights to indicate an occupied spot.
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

conversation in many different directions


You are right. We should discuss common things instead of opening discussion in several direction

It's just not practical to have Red LED lights to indicate an occupied spot.


You are right. It is not required to show red lights. Only green lights should be OK. So it will be something like:

G G G G
A1 A5 A9 B6....

But by this we have to use as many as LEDs as number of total spots in the parking.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tushar Goel wrote:It is not required to show red lights. Only green lights should be OK. So it will be something like:

G G G G
A1 A5 A9 B6....

But by this we have to use as many as LEDs as number of total spots in the parking.



Yes, you have a sensor above every spot in the garage and each sensor will have green LED lights that turn on when the spot is empty.

However, the internal signs just display counts per section. That's all the information customers need.

Example:

I'm driving, I see the sign on the outside of the garage says "53 Available". I say "Great, there's lots of room, let me park in there"

I enter the garage, another sign informs me of this:

A 12
B 9
C 18
D 14

I say, "Ok, the Section B entrance is closer to the store I'm going to so I'll park there since there are still spots open". Meanwhile, the sign outside now says "52 Available".

I drive to Section B of the garage and I look for a green light. There should be nine of them, based on what the sign says but I just need to find one. I find one and pull in to the spot right under the green light. The light goes off, I get out, and go shopping. The internal signs will now say (assuming I'm the only one who parked in the last few minutes):

A 12
B 8
C 18
D 14


I really can't understand why you're so hung up on providing more detail than that. It seems to me that the simplicity and efficiency of it helps the customer just fine. Why do you want to give them more information to process?
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am sorry. I was thinking to make things more simpler. Like instead of finding spot after entering into the garage, i am going to tell the users or
driver itself know which exactly spot is available and go to park there.

But i am thinking now, you are right. I was making things more complex and costly as we need to have separate LED's for each spot. Simply show the users
about available spots and when it enters then shows the internal sign is better and easier option.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tushar Goel wrote:I am sorry. I was thinking to make things more simpler. Like instead of finding spot after entering into the garage, i am going to tell the users or
driver itself know which exactly spot is available and go to park there.


It may sound like a good idea to go into that level of detail but if you really think about it, it's unrealistic. Will drivers really know the exact location of spot "B15"?

If you go to a movie theater and your ticket says you are going to be in "Theater 4, Row G, Seat 12", will you know exactly where that is? No, right? You go in, see signs that say "<--- 1 to 6 | 7 to 12 --->" so you know to go to the left to get to theater 4. When you get to theater 4, the sign there says "<--- 1 - 7 | 8 - 15 -->" So you go in by the right door because you know you're in seat 12. When you get inside, you look at the floor to see the lighted markings. You see "D" right there in front of you, then the next row down closer to the screen is marked "C", so you know that "G" must be further up, away from the screen. You walk up the stairs, saying softly "E".. "F"... "ah, here we are, G!" and you walk across to your seat.

In the case of the parking system, you don't need all this precision. You answer three simple questions: Is there room? What section has room? Where's an open spot in this section? In our example, the answers are "Yes, there's room for 53", "Section B has 9", "Right Here!"
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the discussion so far illustrates the fact that even with what seems to be very simple scenarios, there's a lot of room to make different interpretations. If you don't spell out exactly what the context is and what kind of parameters you have to work with and stay within those bounds, then more often than not, engineers can and will go off in any number of different directions. The term "herding cats" is often used to describe the situation where you are trying to organize a group of developers and get them focused and headed in one common direction. Imagine what it would be like when you have a dozen or so people involved, each with their own ideas of how things should work.
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yup you are right. Each one has its own interpretations. Sometime we need to discuss long to bring everyone on common platform. Thanks again..

So we are clear on this point, Can we start making tests? Which particular item you want us to pick?
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:It's just not practical to have Red LED lights to indicate an occupied spot.



In real life: the parking garage at Istanbul airport uses red LED to indicate an occupied spot and green LED to indicate a free spot.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:

Junilu Lacar wrote:It's just not practical to have Red LED lights to indicate an occupied spot.


In real life: the parking garage at Istanbul airport uses red LED to indicate an occupied spot and green LED to indicate a free spot.


Huh, well call me a Monkey's Uncle then You know, I should probably head out to the Easton Mall and see if their system does that, too. I might just be remembering what I want to remember. The engineer in me still says it makes the system more expensive. I was even thinking of ways to maybe trigger the green lights only when there are cars moving around, like with strategically placed motion sensors. But then again, that's another one of those crazy tangents that I was talking about earlier.
 
Paul Clapham
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Seems to me that a solid row of red LED's tells the customer that there's no parking in this row, carry on and look elsewhere instead of creeping through and examining each space. Whereas an absence of LED's doesn't communicate that information as obviously.

As they say, user interfaces are hard.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tushar Goel wrote:Yup you are right. Each one has its own interpretations. Sometime we need to discuss long to bring everyone on common platform. Thanks again..

So we are clear on this point, Can we start making tests? Which particular item you want us to pick?



I like that first feature I wrote up earlier: External Sign shows available spots in Garage. I have been playing around with Cucumber and Cuke4J but we can stick with JUnit for now.

First test could be allow_entry_when_all_spots_are_available. I'm going to start with a Gate class that knows how many total spots there are in the garage. How about you do the honor of writing out that test code, Tushar? Remember, write only as much test code as you need to have a failing test.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:Seems to me that a solid row of red LED's tells the customer that there's no parking in this row, carry on and look elsewhere instead of creeping through and examining each space. Whereas an absence of LED's doesn't communicate that information as obviously.


The thing is though, you don't have to creep through a row and examine each space. The sensors are mounted on the ceiling of the garage and the green lights are quite visible from a distance. If you're driving around in a section, you can pretty much tell if there are open spots even while you're still a few rows away. You don't have to be right there at the open space to see the indicator; what would be the point of having the light if you had to do that, right? Maybe it's just me and the red LEDs really help but I still think they're redundant. No green light means no available space. Maybe the redundancy helps make the system a little "fault-tolerant"; that is, if there's no green light and no red light, then maybe the sensor is faulty and you might want to check out the space anyway, if you really can't find any green lights elsewhere ¯\_(ツ)_/¯

Anyway, the API I have in mind is a boolean state, so the sensor simply signals that the space is either open or it's not open. Whether or not our hypothetical hardware flips lights between Green and Red or just On and Off state as a result is irrelevant to the software solution. We'll leave that to the hardware guys to figure out
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

How about you do the honor of writing out that test code, Tushar?


I am obliged. I will do it from tomorrow, today i have to go my friend's marriage.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I will lay it out then.

To the uninformed, this may look like just another test. To the astute TDD practitioner, however, it is obviously a detailed design specification. As Jack Reeves wrote, the Code is the Design.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I wrote:Maybe it's just me and the red LEDs really help but I still think they're redundant. No green light means no available space. Maybe the redundancy helps make the system a little "fault-tolerant"; that is, if there's no green light and no red light, then maybe the sensor is faulty and you might want to check out the space anyway, if you really can't find any green lights elsewhere ¯\_(ツ)_/¯


Trying hard to find a way to convince myself that the red lights are helpful, I think I get it.

From the perspective of someone who is totally unfamiliar with the system, without red lights the garage would look like any other garage where you're on your own in finding a parking spot. The red light helps in that it's something different from the normal. Since red is almost universally understood as a negative indicator (STOP, DON'T ENTER, etc.), the association of red with unavailability comes naturally and intuitively once drivers see red lights above spaces that are already occupied.

It would probably be a safe bet to say that a garage that had to go to the trouble of installing a system like this would be relatively busy and therefore, would be mostly occupied during its hours of operation. Having the contrast of red vs green helps make any open green spots even more obvious to customers. At least that's how I've managed to convince my inner engineer.

But then again, what's the cost of a few strategically placed signs that inform customers that they should "Find Green Lights" vs. the cost of all those red LED lights?
 
Raed Tabani
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I also struggle to see the point of the red light, just by showing what spots are available aren't we also saying which spots are not? but I think you're right about it being more "fault tolerant", a faulty no light in an only green system gives the false impression that a spot is occupied where it's not, while the same scenario in 2 colored system could mean either ways. but then again, wouldn't this two light system be a little confusing for Color blind people, especially with the emphasis to use Red and Green(not that I'm an expert in colorblindness )? in a one light system, its says follow the light doesn't matter it's color, it's not racist

anyways, I'd love to give this a go, however I want to do it from the users/drivers perspective that is:
1- the first UI(Activity as I'll be making it in android) will be the external Sign, it shows a number of the available spots and lets user in if at least 1 spot is available.
2- the second UI will be the internal sign, I will make it like the garage with two columns : Section - Number ex A 9
I could go further and make a third activity where the user gets to choose which spot to park in but I think it's unnecessary for now.

but I'm thinking of making the car as an object, and the reason for that is in order to make this more of a real life simulation, I want the car not only to provide stimulus for entry but once parked it would wait for a while then unpark and leave byitself. so it should know for how long to park then invoke getTheHellOutOfGarage();

 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, I won't discourage you from pursuing the "Car" object tack but I will say that I think it's overkill and it will probably turn into a distraction more than it will help you build the functionality that you really need. But experience is that which allows you to recognize mistakes when you make them again; or in this case, when someone else is about to make them.

And why make it for Android? I can't imagine this being a mobile app. Maybe you can have a mobile app client so you can decide if you even want to go to the mall or not but do you really need to start there?

Remember YAGNI?
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Raed Tabani wrote:I'd love to give this a go


How about you try to write the production code for the small test that I wrote a couple of replies ago? See if you can make the test fail, then pass.
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
where did our discussion went, i dint find ours?
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's all there, Tushar. See the *NOTE* that I added to the first post of this topic.

Do you have any production code that exercises the test that I posted?
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, it is being late. I was tired after the party. So here is my production code:



 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Nice. I assume you made sure to see the test fail first by returning false instead of true. Now you would put the code in a vice to squeeze out the bug:

I was thinking about the test name earlier and I noticed that you changed the name I used, allow_entry_when_all_spots_are_available, to isEntryAllowed_should_allow_to_enter_when_all_spot_available. I know I have encouraged this convention in previous conversations and it's great to see that you have adapted it. However, as I said, I got to thinking about the pros and cons of using the actual method name in the test name. One con (maybe?) is that it "leaks" the implementation detail. I'm kind of waffling between the leakiness being good or bad. On the one hand, I know exactly which particular method is being tested. On the other hand, the name of the test gets out of synch with the code if I later decide to refactor the method name.

I think I'm going to come up with a new rule of thumb: for high-level tests that specify general behavior, avoid the actual method names. For low-level, white box type tests, where knowing exactly which method is being tested can be helpful, it's OK to use the actual method name; just be sure to change the test name if you refactor the method name.

In this case, I'm going to stick with the name I chose because the test is really a specification of general behavior, not so much a white box test of the isEntryAllowed method. If you don't mind, let's use these names going forward in the discussion.

Speaking of names, after reading them now, I realize that the specification is a little bit off. The entry gate is not supposed to know or care about what the sensors are reporting (# of occupied vs unoccupied spots). It is only concerned with how many times it has been actuated. So, before moving on, I would refactor these names to: allow_entry_when_garage_is_empty and do_not_allow_entry_when_garage_is_at_full_capacity. I like these names because there's some symmetry between them.

I don't know if you recognized this but these discussions about names are actually about the detailed design and what we've been doing is designing, not coding. Again, it's what Jack Reeves said. So, our tests now become:
 
Tushar Goel
Ranch Hand
Posts: 954
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I think I'm going to come up with a new rule of thumb: for high-level tests that specify general behavior, avoid the actual method names.


Ok. I will do the same but sometime i think we should have name of the method even in case of general behaviour as it is very easy "to identify to whom this
test written for
" even when i am trying to run the case after some time or someone else runs the tests without checking into the test. Even we use white box test
cases, their are the chances we have to change the method name to something better or required.

Regarding the name of the test and assert. I am having doubt. Test name says "allow_entry_when_garage_is_empty" and test says "Hey gate you have a capacity of
10 and are you allowing the entry or not?
" How come gate having capacity or it allow entry or not? Isn't something like: "Hey Garage, do you have any capacity left to
park?
" or something like "Hey Garage, do you allow any more entry?".

If i think about our story "External Sign shows available spots in Garage", i think i am convince to myself to separate section and gate responsibility. Each section having
own responsibility to show available spots but still it doesn't convince me to consider gate capacity and allowing gate to control entrance in terms of section capacity?
Isn't Garage should tell like "Hey Gate, please open it as i am still having a capacity?" or something like "Hey Gate, don't open it till i told you so?"

I have re-read whole previous conversation several times but couldn't convince on this? May be i am falling into the trap or thinking wrongly.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
NET_AVAILABLE = max_capacity - entered + exited

new Gate(10) says "Hey Gate, this is the max_capacity of the garage. If you detect that the NET_AVAILABLE spaces is 0, you can't let any more vehicles come in until somebody exits." This implies that Gate will track how many entered and how many exited. Seems logical to assign this responsibility to the Gate, not the Garage, right?

(Edited for clarity - sorry if you saw what I had before and it confused you)

Or if you prefer, you can imagine the conversation going like this:

"Hey Gate, this garage can only take a maximum of 10 vehicles. Make sure that you track how many have passed through you on their way in. If you see that 10 vehicles have already entered, then don't let any more come in until somebody exits."
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tushar Goel wrote:
If i think about our story "External Sign shows available spots in Garage", i think i am convince to myself to separate section and gate responsibility. Each section having
own responsibility to show available spots but still it doesn't convince me to consider gate capacity and allowing gate to control entrance in terms of section capacity?
Isn't Garage should tell like "Hey Gate, please open it as i am still having a capacity?" or something like "Hey Gate, don't open it till i told you so?"


Another guideline is keeping the number of objects and interactions to a minimum. If I can get away with just the Gate without it having to interact with a Garage or Section, then that's a simpler design. Why make the Gate have to communicate with a Garage object? There's nothing that tells me right now that the Garage is needed. All I need is the Gate.

YAGNI, YAGNI, YAGNI!
 
reply
    Bookmark Topic Watch Topic
  • New Topic