Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!
  • 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

Parking Lot Design

 
Ranch Hand
Posts: 67
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've designed a parking lot according to the specs below:

  • The parking lot has multiple slots.
  • The parking lot can park motorcycles, cars, and buses.
  • The parking lot has small slots, compact slots, and large slots.
  • A motorcycle can park in any slot.
  • A car can park in either a single compact slot or a single large slot.
  • A bus can park only in a single large slot.

  • Please comment on the design.
     
    author & internet detective
    Posts: 40200
    816
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    This part could be changed to be more object oriented. "instanceof" is often a signal that something is wrong. Consider what would happen if you add these three methods to Vehicle. (and overriding in subclasses as needed)

    canFitInSmallSlot()
    canFitInCompactSlot()
    canFitInLargeSlot()

    You could get rid of the instance of and have less if statements/complexity overall. You could also add a new type "Recreation Vehicle" without changing the ParkingLot class at all.

     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you, Jeanne. I have a couple of questions:

  • When I started thinking about the design, I couldn't think of canFitInSmallSlot() as being a behaviour of a Vehicle class. How should I understand it? Is it the responsibility of the vehicle to know which slot it can fit into?
  • I've removed the instance of operators and replaced then with method calls. However, I am not able to see how I can reduce the number of if/else statements.
  •  
    Marshal
    Posts: 25817
    69
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Saikrishnan Srivatsan wrote:Is it the responsibility of the vehicle to know which slot it can fit into?



    That's certainly how it works in real life.

    Although design exercises aren't necessarily a reflection of real life, if your design conflicts with reality then you should certainly ask why that is happening.
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you, Paul. How can I reduce the number of if-else constructs in my code? I am not able to think of any other way to do it. Does it mean I've got some other part of my design wrong also?
     
    Jeanne Boyarsky
    author & internet detective
    Posts: 40200
    816
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Saikrishnan Srivatsan wrote:

  • When I started thinking about the design, I couldn't think of canFitInSmallSlot() as being a behaviour of a Vehicle class. How should I understand it? Is it the responsibility of the vehicle to know which slot it can fit into?

  • In real life, the driver is responsible for knowing this since we don't yet have self driving cars. From a code point of view, it is fine to assume that cars are smarter than that. They are certainly smarter than the parking lot!

    Saikrishnan Srivatsan wrote:

  • I've removed the instance of operators and replaced then with method calls. However, I am not able to see how I can reduce the number of if/else statements.

  • You should wind up with three if statements instead of the 9 you have now.
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you, Jeanne I think I've got it right!Is this correct? Other than this, is my design OK? Kindly suggest areas for improvement. I am trying to hard to improve my object oriented programming skills. I'd like to know if I'm at least on the right track.
     
    Rancher
    Posts: 1090
    14
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Is this an interview's coding exercise?
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    No, this is not an interview's exercise, Chan. I just took the requirements from this source:

    http://andiamopartners.com/S-OOD.pdf

    I am trying to get better at Object Oriented design by implementing a lot of real world applications. This is just one of them.
     
    Jeanne Boyarsky
    author & internet detective
    Posts: 40200
    816
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Saikrishnan,
    That looks much better. That was the only thing that jumped out at me. There's no one "correct" design. I t's a subjective thing. There are "wrong" or "sub-optimatl" designs like when you had instanceof in there.

    And practice design is good. As is asking for feedback on it so you can develop cleaner designs as you go.
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks, Jeanne. When I coded this, I was unsure about a couple of things. So, I will ask those here as well.

    I have a createSlots() method in the ParkingLot class that I call from the constructor. I did this in order to reduce the clutter inside the constructor. But I really think it should be a static method. I am not able to make it work though. Is there a better way? Or should I just do what the method does in the constructor itself?

    The getFirstEmptySlot() method returns null if it's not able to find an empty slot. I have read elsewhere in this forum that returning nulls should always be avoided if possible. Can I code this method better?
     
    Jeanne Boyarsky
    author & internet detective
    Posts: 40200
    816
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Saikrishnan Srivatsan wrote:I have a createSlots() method in the ParkingLot class that I call from the constructor. I did this in order to reduce the clutter inside the constructor. But I really think it should be a static method. I am not able to make it work though. Is there a better way? Or should I just do what the method does in the constructor itself?


    I like that you made it a method. It makes the code easier to read. It can't be a static method because it sets instance variables. It is a private method which is also good. That ensures subclasses can't change the behavior of your constructor. (If you do need to call a public method from your constructor, it should be final.)

    Saikrishnan Srivatsan wrote:The getFirstEmptySlot() method returns null if it's not able to find an empty slot. I have read elsewhere in this forum that returning nulls should always be avoided if possible. Can I code this method better?


    You could have a method that returns a boolean for whether there are empty slots and then calls that method to set it. I think your approach is fine though. It is common to return null when searching though a list and determining a value isn't found. This feels similar.
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Jeanne Boyarsky wrote:You could have a method that returns a boolean for whether there are empty slots and then calls that method to set it. I think your approach is fine though. It is common to return null when searching though a list and determining a value isn't found. This feels similar.

    Thank you. I did initially have a boolean method and also this method, but I felt that I was writing a few lines of code twice, so I decided to remove that method.

    Also, should someone be able to create multiple instances of the Parking Lot? It seems to me that there really should only be one instance of parking lot. Am I over complicating this?

    In reality, each slot could have a vehicle in it. Should my design also reflect that? In other words, should my Slot class store vehicle references in some way?
     
    Jeanne Boyarsky
    author & internet detective
    Posts: 40200
    816
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    The bullet points up top don't require it. Since you are doing this for fun, you are welcome to add any "requirements" to it you want.
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you, Jeanne
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Looking for a suggestion here. I came across this requirement for OO design.

    Imagine you have a call center with three levels of employees: respondent,
    manager and director. An incoming telephone call must be first allocated to a
    respondent who is free. If the respondent can't handle the call, he or she must
    escalate the call to a manager. If the manager is not free or not able to handle it,
    then the call should be escalated to a director. Design the classes and data
    structures for this problem. Implement a method dispatchCaLL() which assigns a
    call to the first available employee.

    Is this something that I can do next? Just want to make sure this is not too trivial.
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    One more question about my design: Am I right in having 3 separate classes for slots, apart from the super class Slot? Is it overdoing inheritance? Should I just have slotType as a field in the Slot class?
     
    Paul Clapham
    Marshal
    Posts: 25817
    69
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It's often a judgment call whether you use separate subclasses or whether you represent the differences between the types by code internal to a single class. So here's an example for you to consider: Suppose that when you turn the page to the next assignment, it asks you to modify the system so that there are parking spaces which can only be used by vehicles with a special "Disabled Person" card. What would you do?
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    With the current specifications, I think I could have just used a field in the Slot class to store its type.

    Paul Clapham wrote:So here's an example for you to consider: Suppose that when you turn the page to the next assignment, it asks you to modify the system so that there are parking spaces which can only be used by vehicles with a special "Disabled Person" card. What would you do?

    If I'd used slotType as an attribute in the Slot class, then I think I'll create a subclass, DisabledSlot, that extends from Slot.

    In my current design though, I think I need to create 3 subclasses, one each from SmallSlot, CompactSlot and LargeSlot. Am I thinking correctly?
     
    Paul Clapham
    Marshal
    Posts: 25817
    69
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Saikrishnan Srivatsan wrote:In my current design though, I think I need to create 3 subclasses, one each from SmallSlot, CompactSlot and LargeSlot. Am I thinking correctly?



    I think you are on the edge of a slippery slope there. The next assignment could be to allow slots to be used only by people with monthly parking passes. Or only by electric-powered vehicles. Or... I don't know, maybe some are closed on Monday nights for street cleaning. There's probably a name for the design pattern (or anti-pattern?) where you have an explosion of subclasses, one for each combination of attributes, and better designers than me could probably name it. Anyway, when you see that happening to you it's a good idea to think twice.
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Yes, Paul. It did feel like a slippery slope when I said that I would have 3 more subclasses for disabled slots. Does it mean that my current design is inflexible? Or, are you hinting that there's a better solution to handle disabled slots even with my current design?
     
    Paul Clapham
    Marshal
    Posts: 25817
    69
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Well, I don't know. Like I said it's often a judgment call, and your design certainly satisfies the requirements you have there.

    But let me just throw this idea out there. What you have is three sizes of parking slot and rules about which vehicles can park in which slots. So far your design has concentrated on slots and vehicles as objects. And you've got the ParkingLot object implementing the rules, as far as I can see. (Sorry, this thread is getting pretty long and I didn't review the whole thing before making that statement.) But as the list of rules gets longer and more ad-hoc (as is often the way in real systems), perhaps the rules should also be objects?

    I'm not saying that's the best way to go; in a real system once you had a bunch of code implementing rules, then you'd just write more code for each new rule rather than refactoring the system to make the rules independent objects. You might be dissatisfied looking at a long list of rule-based code, but that's usually how code maintenance goes. But since you have the luxury of trying out varying designs, why not try this one? I haven't thought it through myself at all so it's possible you will run into problems, but that's the nature of design too.
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you. Generally when designing a system, how much thought should I give to the future? For example, in my design, I think I certainly wouldn't have had separate slot classes for small, compact and large slots if I had known or given thought to the idea of adding "disabled slots" later. I would have had slotType as an attribute instead of having 3 separate classes. But now, with my current design, it looks like I will go down the route of creating subclass after subclass since I didn't have any changes in mind when considering the initial design.

    I think what I really want to ask here is: how much thought should I give to a future change while I'm designing a system now?
     
    Paul Clapham
    Marshal
    Posts: 25817
    69
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    There's a well-known design principle called "YAGNI" -- its Wikipedia article is here: You aren't gonna need it. The article says it better than I would (so read the whole thing), but in summary you shouldn't write code you don't need right away. The idea is if a future requirement comes along, then you just change the system to implement that requirement.

    However that's an answer to a different question than yours. You aren't concerned with design that you aren't going to use right away, you're concerned about design which might be unsuitable in the face of future requirements. Just saying in carefree fashion "Don't worry, just implement something and change it when new requirements come along" isn't necessarily the best strategy, as you suspect. Once you create classes (and worse, database tables) it may not be easy to undo that decision later. So yes, you do need to think about the future to a certain extent.

    But how much to think about the future? That depends on your environment, and there are a lot of factors. How often do requirements change? How much do they change? How much pressure is there to implement these changes as quickly as possible? Also, it's often hard to predict what kind of changes will come along. In the system I used to work on, we had a lot of database fields whose values were originally designed to be "Yes/No" fields but which changed to include various kinds of "Maybe" and "Sometimes". We didn't foresee any of those changes, and we didn't spend much (or any) time considering them in advance.
     
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Saikrishnan Srivatsan wrote:I think what I really want to ask here is: how much thought should I give to a future change while I'm designing a system now?


    Just to add to Paul's excellent advice, there are a few things that you can do to help keep your objects as flexible as possible:
    1. Never, ever, ever, make member fields anything but private. Personally, I wish it was the Java default, because even making them protected - which might on the surface seem like a sensible thing to do - can open you up to all sorts of problems.
    2. Keep objects immutable unless you have a very good reason not to.
    3. Keep classes final unless you have a very good reason not to.
    4. Don't provide any more public methods than you absolutely have to. Java's List class (java.util.List) is, IMO, a prime example of a class that has far too many public methods; and Calendar is even worse.
    5. Program to interfaces.

    Now none of the above is going to help you with the "thinking ahead" part, but what information hiding and interface-based programming do is allow you to change things, if needed, later on with the minimum of fuss.

    HIH

    Winston
     
    Marshal
    Posts: 70261
    282
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    They appear to have worked on the principle that library classes are permitted lots of public methods. When you design your own classes, you give them as few methods as you can get away with. When Sun designed these library classes they appeared to have thought, “maybe somebody will require a copy‑constructor for Strings,” and provided one. Similarly those classes with many methods, just in case somebody needs them.
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Campbell Ritchie wrote:They appear to have worked on the principle that library classes are permitted lots of public methods...


    I'm sure you're right, but I don't, in general, agree with the philosophy.

    Why, for example, provide a bulk constructor and a bulk load method? Why provide indexOf() and contains()? I understand that it's partly dictated by interface hierarchies, but I think perhaps that List wasn't the best thought-out one on that score.

    My 2¢

    Winston
     
    Campbell Ritchie
    Marshal
    Posts: 70261
    282
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote: . . . Why provide indexOf() and contains()? . . .

    If you implement contains like this:-

    I think I agree with just about everything you said.
     
    Ranch Hand
    Posts: 80
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Folks...
    Would it be better/worse if each vehicle knew the slot it was parked in and each slot knew the vehicle that is parked on it ie. Vehicle should have a ref to Slot and viceversa ?. That ways, the signature of the unpark could be unpark (uniqueToken, slotNumber). Unpark could simply get the slot on that number and free it up.

    Please critique
     
    Marshal
    Posts: 15884
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    First, I'm going to move this to a more appropriate forum...
     
    Junilu Lacar
    Marshal
    Posts: 15884
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    sandeeprajsingh tandon wrote:Hi Folks...
    Would it be better/worse if each vehicle knew the slot it was parked in and each slot knew the vehicle that is parked on it ie. Vehicle should have a ref to Slot and viceversa ?. That ways, the signature of the unpark could be unpark (uniqueToken, slotNumber). Unpark could simply get the slot on that number and free it up.

    Please critique



    Let me start off with some praise: Good effort so far. It's good that you're doing this and asking for feedback. It shows a level of interest and dedication that most people don't have.

    I see you have already been given some great advice such as YAGNI and avoiding instanceof. I haven't read through the whole thread in detail but I don't think anyone has told you this yet: those aren't actually requirements that you have there. They are high-level statements of a particular design's capabilities and attributes. Notice how each of those sentences has the word "can" or "has"? That's what tells you that these are not really requirements.

    It's the same as saying "Design an animal that has seventeen legs." That's not a requirement either but rather an implementation suggestion. To get to the real requirement, you have to dig deeper. One technique that helps is to ask 5 whys. That technique was originally meant to find the root cause of a problem but many people also employ it to uncover the real requirement that's hiding behind an implementation suggestion.

    Consider this problem statement instead:

    "Just the Right Spot Parking Lot"

    Background: I'm the owner of a parking lot business and I need a better system to manage my facility. My facility is in a great location downtown and I have an opportunity to buy one of two adjacent lots in the next two years if I want to expand my business. One lot costs more than the other so I want to be able to determine the patterns of usage of my facility so that I can decide which one, if any, would be worth making an investment in so I can maximize my profit and return on investment. At the same time, I want to put in some level of automation and intelligence in my lot to make it easy for customers and potential customers to use my facility.

    Requirements:
    1. I need a report that shows me the usage levels over various periods of time: hourly, daily, weekly, monthly. I should be able to see the kinds of vehicles (motorcycle, car, bus) , number of vehicles, and durations.
    2. I need to know how many vehicles had to be turned away because of lack of space. Same kind of report as #1: kinds of vehicles, #s per hour, day, week, month.
    3. In order to gather information for #2, my attendants need to know the number of available spots open for each kind of vehicle so they can decide whether or not to turn away a vehicle due to space limitations.
    ...

    --------
    I could go on but let's stop there for now and discuss. Do you see how these are closer to being actual requirements than what you originally had?

    How does this affect your current design? Do you still think you need the Vehicle hierarchy of classes?
     
    Junilu Lacar
    Marshal
    Posts: 15884
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    In case you miss my point, here's a more direct answer: I think you need a better understanding of the problem you're trying to solve before you decide on what a Vehicle can/should be responsible for. I would submit that you probably don't even need a Vehicle hierarchy.

    There was mention previously about how things work in the real world. Sure, you should take cues from the real world of objects but it is often a trap to model your objects and their relationships too closely to the real world. Besides, does a Vehicle actually need to know anything in the context of a Parking Lot problem?
     
    Junilu Lacar
    Marshal
    Posts: 15884
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Bitten again by a zombie thread. That's fine though, there might be a few people hanging around who might find this worth a look.

    I noticed that the OP mentioned "spec" rather than "requirements" and I just wanted to point that out and note that it doesn't change the fact that there are no clearly stated needs or problems that are to be addressed and used to guide the design thought process. Until you have a concrete context, you'll just spend time on "what if"s and coming up with anticipatory/speculative designs which, IMO, is largely a waste of time.
     
    Ranch Hand
    Posts: 50
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    sandeeprajsingh tandon wrote:Hi Folks...
    Would it be better/worse if each vehicle knew the slot it was parked in and each slot knew the vehicle that is parked on it ie. Vehicle should have a ref to Slot and viceversa ?. That ways, the signature of the unpark could be unpark (uniqueToken, slotNumber). Unpark could simply get the slot on that number and free it up.

    Please critique


    hi sandeeprajsingh(why didn't I just copy and paste your name )
    I'm not sure I'm in a position to be giving a critique, but nevertheless I want to share what I think.
    I could understand why a car would need to know the slot where it's parked at, so it could serve as a reference for the car Object. so for example, you were asked to move a specific car to another location, It could easily be done by asking the car which slot it's at and then just swap slots. however, isn't it enough for slot to just know if it's occupied or not? not to mention, if the slot is a reference for car object, doesn't it necessarily mean that it knows which car is on it( by saying slot[number].getname())?

     
    Raed Tabani
    Ranch Hand
    Posts: 50
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    hi Saikrishnan,
    what a great topic, personally I found it so helpful and it got me excited to take a shot at the Parking Lot design myself.
    before I do that, however, I'm wanted to ask you a couple of questions regarding your design

    1- why did you choose to make Car, Bus, MotorCycle a subclass of Vehicle instead of "code internal to a single class" as Paul mentioned? I'm not sure if this is the right analogy, but this does remind me of a card "game" that I did and more precisely the Card class. your way seems to me like having each suit(Hearts,Spades..etc) as a SubClass of Card where it could have easly been a String Value called suit or an enum.

    2- why did you decide to make each slot individually then fill them one by one rather than having a slot object hold an arraylist of cars plus rules?

    3- do your slots serve as references to vehicle objects? I thought it was "odd" that your parking lot slots held Slot Objects instead of Vehicle


     
    Junilu Lacar
    Marshal
    Posts: 15884
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Raed Tabani wrote:
    I could understand why a car would need to know the slot where it's parked at, so it could serve as a reference for the car Object. so for example, you were asked to move a specific car to another location, It could easily be done by asking the car which slot it's at and then just swap slots. however, isn't it enough for slot to just know if it's occupied or not? not to mention, if the slot is a reference for car object, doesn't it necessarily mean that it knows which car is on it( by saying slot[number].getname())?


    In "you were asked to..." who is "you" and who is asking to do this? You, the programmer? In what context would you, the programmer, be asked to move a car to a different spot? Why do you need to move it? To me this just sounds like conjecture and imagining that software objects are somehow magically connected to the real objects. This is part of the trap I mentioned and the futile and fruitless thought exercises that come out of it.

    Ask yourself, if this were a real system being used by real people in a real parking lot, what scenario would require a change in the parking spot to be reflected in the system? Does it even matter that someone moved a Vehicle from one spot to another? Why does it matter? How does modeling some kind of behavior in the system make it easier to understand the code? How does it help organize the actions that must take place to update the current system state? What effects do these actions have on the user/customer? Do you have any legal right to touch someone's vehicle while it is parked in your facility? What happens when you try to move a car and the alarm goes off?

    Sure, this is just an exercise but to make anything you "learn" from it applicable in a real-world scenario, you also have to keep the context of the problem realistic to some extent.
     
    Raed Tabani
    Ranch Hand
    Posts: 50
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator


    In "you were asked to..." who is "you" and who is asking to do this? You, the programmer? In what context would you, the programmer, be asked to move a car to a different spot? Why do you need to move it? To me this just sounds like conjecture and imagining that software objects are somehow magically connected to the real objects. This is part of the trap I mentioned and the futile and fruitless thought exercises that come out of it.

    Ask yourself, if this were a real system being used by real people in a real parking lot, what scenario would require a change in the parking spot to be reflected in the system? Does it even matter that someone moved a Vehicle from one spot to another? Why does it matter? How does modeling some kind of behavior in the system make it easier to understand the code? How does it help organize the actions that must take place to update the current system state? What effects do these actions have on the user/customer? Do you have any legal right to touch someone's vehicle while it is parked in your facility? What happens when you try to move a car and the alarm goes off?

    Sure, this is just an exercise but to make anything you "learn" from it applicable in a real-world scenario, you also have to keep the context of the problem realistic to some extent.



    I was thinking of OP's "program" as a parking manager or a Valet, where you get Vehicle Objects and choose the appropriate slot to park it in, so by "you" I guess I was referring to the user. but I think I understand what your saying, which is, if there's no need for something why make it or perhaps don't just make something because that is how it is in real life, but think of it as why do I need to do this and does it matter? in case of changing slots aka movingVehicle(), I think if we had a GUI where each slot corresponds to a specific View , then wouldn't it matter?

     
    Junilu Lacar
    Marshal
    Posts: 15884
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    A few bad things that you are picking up from these unsubstantiated, no-context thought exercises about what your software objects should be able to do:
    1. You are ignoring the context of the problem. This results in designs that may be fun for you, the developer, to come up with but they are useless in solving the users' problems or meeting their needs because... —"oh by the way, what exactly did they need again?"— Exactly.
    2. You are making pre-emptive/predictive design decisions and this leads to wasteful over-engineering and unnecessary complexity
    3. You are not thinking about how to test your system. That's the worst habit to develop and leads to much pain and suffering in the real world.

    So, first come up with a problem statement. Not a design spec but a realistic problem statement. Kind of like what I suggested a few posts back, only better.
     
    Raed Tabani
    Ranch Hand
    Posts: 50
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    you know as I was having a go at this exercise, and so many others. I did struggle with the lack of context, as in what problems this program supposed to solve and what are the needs of the users . so I started to come up with these scenarios, imaginary problems , that may or may never be needed by the user, but nevertheless fun to try . but if I was to summarize what your saying is to define the set of bare minimum necessary problems, rather than Objects, as the context for the program?
     
    He baked a muffin that stole my car! And this tiny ad:
    Thread Boost feature
    https://coderanch.com/t/674455/Thread-Boost-feature
      Bookmark Topic Watch Topic
    • New Topic