How should i "build" things now I've implemented polymorphism? (Java, sim game)

Question

Hi all. I'm working on a small java game which is a sort of clone of the 1995 game Theme Hospital. I've recently been working on the GUI and the Level structure now I have the path finding and grid working. My current way of "building stuff" consists of one room and one reception desk, and it works ok so far, but I need to implement a way to add different types of rooms and items. Here is my current code on the button press for the creation of the object (http://snipt.org/lUm).

I'm sure there must be a better way to do this! My implementation is poor, I know, but I have only recently began to understand how to use abstract classes and interfaces.

Actually setting the properties of the room or item, I currently have no issue with. I am thinking ahead, but I love how I get different opinions on the best way to do things here on Stack. At ideas on how such a thing should be achieved? Any examples of this sort of thing? I would search it, but I'm not really sure what to search for, as I don't if what I'm doing has an exact name.

I'm sorry if I haven't been too clear exactly what I'm talking about. I will gladly answer any further questions on this, and or upload more sections of code as needed or requested.

Thanks in advance for your time and thoughts!

Answer 1

Check out the factory pattern. The factory is a means of creating objects by providing parameters, and getting objects back that adhere to a common interface. The implementation, however, is determined by the factory. The calling code does not need to know this.

By encapsulating the object construction in another object (the factory), the mechanics of selecting the particular object to build is abstracted away from the calling code. You can easily provide further subclasses at a later date by only modifying the factory itself.

So in your example code, the buildMe() method is a form of factory. It takes some parameter specifying what's required to be built - a Room or a ReceptionDesk. Both these would implement the same interface (a HospitalComponent?) and the calling code would then place that component within the hospital. You can add further subclasses of HospitalComponent to the factory (an OperatingTheatre?) and the calling code doesn't have to change.

It's worth investigating design patterns (in this scenario, check out this list of creational patterns) to understand different ways of using objects to solve common problems, and for how to communicate your solutions with other people. The Gang-of-Four book is the bible for this subject.

Answer 2

Polymorphism might be overkill for what you are doing.

Personally, I would just have a Room class, with a table of the values for each building (max size, cost per tile etc.). Then, when you build a new room, get the matching table entry, and create your Room object with the details from the table.

This may not be the best practice, and it probably goes against Java conventions (I came to Java from dynamic languages) but in terms of lines of code that need changing to make a new room, it's the lowest I've found.

Answer 3

What you have now is one class with a bunch of static functions. It isn't very OOP--the class is just a way to group all the functions in one file.

If you go the OOP route, you'd want a Room base class, then OperatingRoom, ReceptionistDesk, Bathroom, Office (for Staff), MRIRoom, WaitingRoom, and maybe even Hall would be child classes of Room.

public class Room {
    protected int width, length;  //how many squares wide/long the room is

    protected int x, y;  //where it is on the gride

    protected float buildingProgress;  //how far construction has come

    protected bool isReady;  //is the building ready for use?

    protected Person occupants[];  //some list/array of people currently in the room

    protected Person resident;  //the person 'in charge' in the room--the receptionist, manager, MRI technician, etc etc.
}

Answer 4

I'd think carefully before modeling this problem with polymorphism.

The question is: what fundamentally different behavior will each type of Room exhibit? What's common between all of them?

Polymorphism isn't always the answer. Composition can sometimes keep things more flexible. A data driven solution, as recommended earlier, might be best of all.