Identify methods on OOP

Question

I am struggling to define methods in OOP. Currently I am practicing with this scenario: "A hospital has started the development of a new system to keep records of analysis done by patients and the doctor who asked them."

I defined four classes: Patient, Doctor, Analysis and Hospital.

• Patient: represents the person who goes to the hospital. May know which analysis has done.
• Doctor: represents a professional of medicine. May know which analysis has requested.
• Analysis: represents a study requested by a specific doctor for a specific patient.
• Hospital: keeps track of doctors, patients and analysis.

This is the uml class diagram

Now I am not comfortable with this diagram because:

1. If any method has access to a patient, then it could exec joe.addAnalysis(a) but analysis "a" is never added to Hospital. This would generate inconsistency.
2. Same as above but with doctor instead of patient.

So in my second attempt, I removed methods addAnalysis() and getAllAnalysis() from Patient & Doctor. Now Hospital has

• getPatientAnalysis(p: Patient): Analysis[0..*]
• getDoctorAnalysis(d: Doctor): Doctor[0..*]

But in this case I wouldn't be able to ask a patient for their analysis list directly. Same goes to doctors.

So the question is: Is my second attempt better? If so, then what happens with "patients knows which studies they've done"?

Answer 1

I am struggling to define methods in OOP

You sure are. What is any of this supposed to do? This is a huge pile of inactive nouns. You need some verbs. These might as well just be database tables.

This is premature design. You need to develop your requirements first so you understand your needs. To demonstrate I'll make up some for you.

hospital.bill(patient);
patient.printIDLabel(labelMaker3rdFloor);
doctor.prescribe(patient, medication);

I've said it with pseudo code but you are free to use the whole requirements sentence construct. "As a doctor, I need to be able to update patient analysis with medication prescriptions."

Your design should focus on enabling these requirements. Not take a list of nouns and obsess on how they're constructed. This is not the same as designing tables for a database. Code has to do something with data. You're not the first to struggle with this. See Object Relational Impedance Mismatch

Answer 2

It seems to me like you are conflating several different responsibilities:

• One is creating an analysis,
• an other is storing the analysis, and
• the last is navigation between patients, doctors, analyses, and hospitals

The doctors probably are the ones that create the analyses. The hospital probably has the IT systems that store the analyses.

By this, doctors might provide analysis creation, while hospitals provide adding an analysis to the records system.

As far as navigation goes, we want to be able to navigate from patient to their analysis, from patient to their doctors, from doctors to their analyses, from the hospital to their analyses, from hospital to their patients, from hospital to their doctors, from analysis to the patient, doctor, and hospital.

Modeling can be detailed using objects technology or using relational technology. Personally, I prefer to think of the relational model first, meaning to think of tables and their inter relations before diagramming classes diagram with their inter relations.

The main reason is that the relational model offers a higher level view of relationships and (bi-directional) navigation just falls out no matter whether 1:N or N:M. (Another reason is that the relational model represents our long term persistence, rather than short term behaviors of code. And yet another reason is that relational model encourages normalization.)

Whereas using objects technology we tend to think more in terms of uni-directional references. However, in theory it doesn't really matter which technology to diagram.

The main thing to realize is that with unidirectional relationships we will probably have to create references in both directions to get bidirectional navigation (unless we were to resort to cumbersome searching). This means that information is being duplicated, but that's just how that is with objects technology. (This is another one reason that I prefer the relational model because normalization tends eliminates/reduces duplication.)

So, using an objects technology, we'll have references and collections that support the navigation we want, even though some of the objects (like analyses) are shared among several collections. So, while navigation might have to be supported everywhere, it is important to identify the proper responsible entities for creating information, making changes, and storing information and keep that understood separately from general navigation.