Simple object oriented design for a patient system

Question

I want to model this scenario in object oriented language:

• A hospital has number of patients
• A patient can have zero or more medical conditions
• A medical condition is identified by name and date

Please review my code and tell me:

1. What can I do to incorporate object oriented fundamentals like reusability and extensibility?
2. Do I need to implement an equals method in the MedicalCondition class?
3. Do I need to initialize all the instance variables in constructor?

import java.util.Date;
import java.util.*;
import java.text.*;
class Patient
{
    private String name;
    private String streetAdress1;
    private String phoneNumber;
    private String streetAdress2;
    private String zipCode; //I really dont need to preform any numerical operations.
    private List<MedicalCondition> mcList;

    public Patient(String name) //Public for constructor.
    {
        this.name = name;
        mcList = new ArrayList<MedicalCondition>();
    }  

    public void setName(String name)
    {
        this.name = name;
    }

    public String getName()
    {
        return name;
    }


    //All setter and getters

    public void addMedicalCondition(MedicalCondition mc)
    {
        mcList.add(mc);
    }

    public void deleteMedicalCondition(MedicalCondition mc)
    {
        mcList.remove(mc);
    }

    public List<MedicalCondition> getMedicalConditions()
    {
        return mcList;
    }

    public String toString(){
        return name;
    }
 }   

class MedicalCondition
{
      private String nameOfCondition;
      Date dateOfReport;

      public MedicalCondition(String nameOfCondition,Date dateOfReport)
      {
          this.nameOfCondition = nameOfCondition;
          this.dateOfReport = dateOfReport;
      }

      public String toString()
      {
          return nameOfCondition;
      }
 }


 public class HelloWorld{

     public static void main(String args[]) throws ParseException{
        Patient p1 = new Patient("Mike");

        DateFormat format = new SimpleDateFormat("mm/dd/yyyy");
        MedicalCondition mc1 = new MedicalCondition("Diabetes",format.parse("03/23/2000"));
        p1.addMedicalCondition(mc1);

        System.out.println(p1);
        for(MedicalCondition mc : p1.getMedicalConditions())
        {
            System.out.println(mc);
        }

        p1.deleteMedicalCondition(mc1); //Delete the condition

         System.out.println(p1);
        for(MedicalCondition mc : p1.getMedicalConditions())
        {
            System.out.println(mc);
        }
     }
}

Answer 1

Bracing style

You started off with Allman-style bracing approach, but switched to the Java convention for HelloWorld and its main() method. Regardless of the styles you choose, please be consistent on this front. :)

Medical condition dates

Your medical conditions carry a start date, but should they also have an end date? Or are we only talking about incurable medical conditions here? While we're at it, Java 8 has new 'Time' APIs with a different (and better) approach to modeling chronology, so you may want to use the newer LocalDate class.

OK, now I get it... you delete medical conditions when they are cured. If you need to preserve medical history, you now know what you can do too...

Throwing Exceptions

public static void main(String args[]) throws ParseException

I understand HelloWorld is something like a test class to see your implementation in action, but still try to avoid doing something like this, especially when it's your main() method. One wrong input will simply cause your test class to quit with a stacktrace. It will be better if you have a method to handle the parsing and any possible errors. For example, if you want to default to the current date in case of parsing errors:

private static LocalDate parse(String date) {
    // using the new time APIs
    try {
        return DateTimeFormatter.ISO_LOCAL_DATE.parse(date, LocalDate::from);
    } catch (DateTimeParseException e) {
        return LocalDate.now();
    }
}

equals() implementation

Do I need to implement an equals method in the MedicalCondition class?

Your call. :) The longer answer is, what does it mean when a medical condition is-equal to another? Same condition and date? How helpful will such an equivalence be? To 'group' patients by the same medical conditions? If you don't have a strong case for this, you probably wouldn't want to implement it first.

Adding medical conditions

In this regard, I will recommend your existing approach over @Amr Ayman's answer. This is mainly because your Patient class should know what it means to add a medical condition, instead of letting callers of your Patient instances 'figure that out'. A better refinement is to wrap the instance returned by getMedicalConditions() with a Collections.unmodifiableList(): this will prevent callers of the method to modify the list's contents directly, such as wiping them outright.

Actually, on this note, you can also consider making your MedicalCondition class immutable, and I shall leave that as an exercise for the healthy reader...

Answer 2

Redundant Imports

You import java.util.Date then import java.util.*, clearly the first is a redundant statement.

Readability

This:

private String name;
private String streetAdress1;
private String phoneNumber;
private String streetAdress2;
private String zipCode;

is exactly the same as this:

private String name, streetAdress1, streetAdres2, phoneNumber, zipCode;

only the second is easier to read. This is a matter of preference, however, as it seems from the comments.

Also, why do you declare zipCode if you're not going to use it ? I assume that's just a draft.

Class Design

I think you don't need addMedicalConditionsince it's just a shorthand of saying: getMedicalConditions().add(). The same applies for deleteMedicalCondition.
Note that this is the approach used by javafx.scene.layout.Pane and is thus the preferred approach.

If you still want to keep these methods, at least follow these guidelines:

1. Prefix MedicalCondition with the function's corresponding term in List. For example, rename deleteMedicalCondition to removeMedicalCondition, that way it'll be easier to follow when you return to it later.

2. Accept variadic arguments for convenience. In which case, add a plural s.

Also, you shouldn't use String for any kind of data.
For example:

1. Street addresses and zip codes should be in a separate class responsible for locations.

2. Phone number should be in a separate class as well responsible for communications, possibly incorporating additional functionality such as grouping of phone numbers in order of priority.

Also, why use setters if you are just going to accept all values into name ? In this case mark name public. See purpose of getters and setters.

Variable Naming

I suggest you improve your variable naming habits so that variables hold a representative name of what it's used for while being short enough for typing.
For example:

1. streetAdress1 -> mainAddress
2. streetAdress2 -> otherAddress
3. mcList -> medicalConditions (variable names should not contain their data types)

Here's an idea of what I'm talking about:

class Patient
{
    public String name;
    private Location location;
    // Connection should be an abstract class with subclasses such as PhoneConnection, InternetConnection, etc.
    // The list should be ordered by means of priority and availableness.
    private List<Connection> connections;
    private List<MedicalCondition> conditions;

    public Patient(String name, Location location, Condition...conditions)
    {
        this.name = name;
        this.location = location;
        this.conditions =  new ArrayList<MedicalCondition>(Arrays.asList(conditions));
        this.connections =  new ArrayList<Connection>();
    }  

    public void setConnections(Connection...connections)
    {
        this.connections.addAll(Arrays.asList(connections));
    }

    public List<MedicalCondition> getMedicalConditions()
    {
        return mcList;
    }

    public String toString(){
        return name;
    }
 }

To answer your questions

1. I think encapsulation is the only needed concept in this case.
2. MedicalCondition should be an enum because, theoretically, it only accepts a certain set of possible values. For example, diabetes, cancer, etc. As you might need a specific set of MedicalConditions, using an enum would be highly-inefficient and probably an overkill. A class would be the optimal solution, and by doing that, we are sacrificing the reliability of an enum for the (technical and usable) convenience of a class. To cope with that, at least add validation mechanisms for the MedicalCondition constructor depending on possible use cases.
3. No, only the important ones. For example, you can leave the Connection class to be used if asked for specifically in a method, say, setConnections.