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 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"?

  • Suggestion: you may want to read up on "aggregate root" or ask your teacher about it
    – rwong
    Jan 15, 2018 at 13:05
  • A class diagram can tell you what methods exist but not what methods are called. If you want to express tha constraint that each analysis must always be related to a hospital then add a "i" at the bottom of the vertical arrow in the center. [Hospital](1)->(0..*)[Analysis] but again this does not mean that any particular method is called. Jan 15, 2018 at 13:19
  • 1
    If you really want to do this formal analysis stuff, you need to start by identifying use cases (e.g. "as a doctor, I want to record the patient analysis I've just done") and then you can choose the methods you need based on that. Jan 16, 2018 at 13:56
  • @rwong Thank you, that's the real answer I was looking for. My question wasn't clear so I the answer for the title is the one that CandiedOrange replied. Jan 18, 2018 at 0:20
  • @Goyo I forgot that. That would reflect the domain model but implementing the current class diagram would be a pain, would not? My final model has a AnalysisRepository class which works as an Aggregate root for analysis. So, Patient::getAnalyses() will query that repository, and Hospital::addAnalysis(Patient, Doctor, analysisdata) will add the analysis to the repository. This way I will be covering the model's integrity. Jan 18, 2018 at 0:36

2 Answers 2


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.

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


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.

  • The question was specifically about OOP, not relational modeling. I think the confusion between these two is exactly the problem. Jan 16, 2018 at 10:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.