Task 2 — Gym Training Management

Objective

Create a model for managing private training sessions inside a gym.

Each training session connects:

• a coach
• a client
• a training time
• an exercise set
• a training duration

The implementation must also provide operations for reading and updating training information.

Training

Each training contains the following information:

Training ID
Training Time
Coach
Client
Exercise Set
Training Length

A possible model is:

type Training struct {
    ID          string
    Timeline    time.Time
    CoachID     string
    ClientID    string
    ExerciseSet []string
    Duration    time.Duration
}

The exact field types may be adapted to the implementation.

Person Information

Both coaches and clients contain common personal information:

ID
First Name
Last Name
Phone Number

A shared model may therefore be useful.

For example:

type Person struct {
    ID          string
    FirstName   string
    LastName    string
    PhoneNumber string
}

Coach

A coach may be modeled using the shared personal information.

For example:

type Coach struct {
    Person Person
}

No additional coach-specific attributes are required by the original task.

Client

A client contains the shared personal information and two additional attributes:

Height
Weight

For example:

type Client struct {
    Person Person
    Height float64
    Weight float64
}

Relationship Between Models

A training references one coach and one client.

Conceptually:

Training
├── Coach
├── Client
├── Timeline
├── Exercise Set
└── Duration

The implementation may store:

• embedded Coach and Client values
• references by ID
• another equivalent relationship model

Using IDs is often useful when coaches and clients are stored independently.

Custom Data Module

Create a separate custom module containing example data for:

• coaches
• clients

For example:

coaches
clients

The original task allows the implementation to define its own example lists.

The important requirement is that training records can reference valid coach and client records.

Training Store

A useful implementation may also create a training collection.

For example:

type TrainingStore struct {
    Trainings []Training
    Coaches   []Coach
    Clients   []Client
}

The exact design is left to the implementation.

Required Operations

The implementation must support the following operations.

Get Coach Data by Training ID

Given a training ID, return the coach assigned to that training.

Conceptually:

GetCoachByTrainingID(trainingID)

The operation should:

1. find the training
2. obtain its coach reference
3. find the corresponding coach
4. return coach data

Get Client Data by Training ID

Given a training ID, return the client assigned to that training.

Conceptually:

GetClientByTrainingID(trainingID)

Get Training Start Time

Given a training ID, return the time when the training begins.

Conceptually:

GetTrainingTimeline(trainingID)

Get Exercise Set

Given a training ID, return the complete exercise set.

Conceptually:

GetExerciseSet(trainingID)

Update Training Time

The training timeline must be changeable.

This represents a case where the scheduled training time has changed.

Conceptually:

UpdateTrainingTimeline(
    trainingID,
    newTimeline,
)

The operation should modify only the selected training.

Update Exercise Set and Training Length

The implementation must also support changing:

Exercise Set
Training Length

Conceptually:

UpdateTrainingPlan(
    trainingID,
    newExerciseSet,
    newDuration,
)

Both values belong to the training session and should be updated together when the training plan changes.

Lookup Result

Operations should distinguish between:

training found
training not found

For example, a lookup should not silently return an empty coach or client when the training ID does not exist.

A possible result style is:

value, error

or an equivalent mechanism in the chosen language.

Referential Validation

When creating a training, the implementation should ensure that:

• CoachID refers to an existing coach
• ClientID refers to an existing client

A training should not reference entities that do not exist in the configured data store.

This validation follows naturally from the model relationships.

Training Validation

Useful validation includes:

• Training ID is not empty
• Coach exists
• Client exists
• Timeline is valid
• Exercise set is not empty
• Duration is greater than zero

The original task does not prescribe a detailed validation system, so the exact validation rules beyond valid model relationships may be chosen by the implementation.

Example Data

Example coach:

Coach{
    Person: Person{
        ID:          "coach-1",
        FirstName:   "Alex",
        LastName:    "Grant",
        PhoneNumber: "+381641111111",
    },
}

Example client:

Client{
    Person: Person{
        ID:          "client-1",
        FirstName:   "Ben",
        LastName:    "Walker",
        PhoneNumber: "+381642222222",
    },
    Height: 185,
    Weight: 86,
}

Example training:

Training{
    ID:       "training-1",
    CoachID:  "coach-1",
    ClientID: "client-1",
    ExerciseSet: []string{
        "Squat",
        "Bench Press",
        "Pull-Up",
    },
}

The actual example values may be changed.

Requirements

The implementation must:

1. model a training session
2. model coaches
3. model clients
4. store client height and weight
5. create custom coach and client collections
6. retrieve coach data using a training ID
7. retrieve client data using a training ID
8. retrieve training start time
9. retrieve the exercise set
10. update training time
11. update exercise set
12. update training duration
13. execute examples for the required operations

Modeling Goal

The main modeling relationship is:

Coach       Client
   \         /
    \       /
     Training
        |
        +-- Timeline
        +-- Exercise Set
        +-- Duration

The training session is the central entity.

Coach and client information should remain independent domain data rather than being duplicated inside every training record.

Optional Extension

An extended implementation could add:

• training status
• maximum duration
• trainer availability
• client scheduling conflicts
• training history

These are not required by the original task.