How could you improve on the design of the class below by rewriting the code
using no conditional statements or operators?
Motivate your redesign.

class MyRegister { 
  List employees = new ArrayList(); 
  List customers = new ArrayList(); 
  List suppliers = new ArrayList(); 

  void register(Person p) { 
    if (p instanceof Employee) { 
      employees.add(p); 
    } else if (p instanceof Customer) { 
      customers.add(p); 
    } else if (p instanceof Supplier) { 
      suppliers.add(p); 
    } 
  } 
}
 
class Person {...} 
class Employee extends Person {...} 
class Customer extends Person {...} 
class Supplier extends Person {...}

(a) What design pattern does the code below illustrate? (Pick one.)
(b) How did you come to the conclusion you did? (Present some arguments!)
(c) Draw a simple UML-diagram for the pattern. Change the names to some more informative ones in the diagram.

(Note: This is not a clear-cut case: It is possible to defend the choice of at least two, maybe three,
different patterns. If you can provide good arguments for the pattern you choose, it will be accepted.)

package christmaspresent; 

public class PatternXTest { 
    public static void main(String[] ohWhatANight) { 
      MerryChristmas christmasTree = new HoHoHo(); 
      MerryChristmas theGrinch = new HappyNewYear(christmasTree); 
      theGrinch.jinglebells(1); 
      theGrinch.jinglebells(-1); 
    } 
}

interface MerryChristmas { 
    public void jinglebells(int santaClaus); 
}

class HappyNewYear implements MerryChristmas { 
    private MerryChristmas merry; 

    HappyNewYear(MerryChristmas arneWeise) { 
        merry = arneWeise; 
    }

    public void jinglebells(int reinDeer) { 
      if (reinDeer>0) { 
          merry.jinglebells(reinDeer); 
      } else throw new SantaIsDrunk(); 
    }
} 


class HoHoHo implements MerryChristmas { 
    private int rudolf; 
    public void jinglebells(int reinDeer) { 
        rudolf = reinDeer; 
    } 
} 

class SantaIsDrunk extends RuntimeException {}

The system requires obtaining several different sets of data for the configuration purposes.
Configuration data are represented with key value pairs.
The value of such pair could be numbers, string, boolean, byte[](binary) and so on.

It requires to design the intermediate layer between application and some repository for storing and retrieving these sets.
This layer should be disigned in the way, which does not depend on any particular repository implementation (databse agnostic way).
The repository can be any like: SQL database, file, external service and so on.

It requires to design a system for authorization to operate with properties(fields) of domain objects.
Application behalf of an user can do following operation with domain object properties: read, create, modify.

There are the following authorithation categories: users, user groups.
Each category can have its own rights, which describe possible operations.
Each property of the domain object must be assigned categories with the corresponding rights
to provide appropriate access model.

Description:

1. A box, which physically contains all other components;
2. Product slots, which physically contains products to sell.
   The machine contains multiple slots.
   Each slot can contains only one type of product to sell (no mix).
   Also there is a shared or dedicated per slot, device to deliver product unit(s) to output container;
3. Product dispenser is the space where all bought products are moved from slots
   and where buyer can pick up them;
4. A control panel - to interact between buyer and the machine.
   It contains keyboard and display.
   The control panel serves for selecting products, informing about total sum to pay,
   helping with payment (enter pin code, informing to insert card, cancellation of payment and so on);
5. Money acceptance mechanisms is for transfering money for purchase. It includes such mechanisms as:
   5.1. Coin acceptor - is to pay with cons;
   5.2. Cashless card acceptor - is to pay with Master/Visa cards.
6. Money dispenser mechanism is to return money to buyer. It is used for cancellation or return of change.
   There are such dispensers in the machine:
   6.1. Coin dispenser;
7. Internal computer which manages the whole machine;
8. Interface to service the machine.

1. There are 5 slots, 10 products per slot;
2. For service operation it uses the same Control panel + some authentication;
3. The vending machine is not connected to internet.

Basic Scenarios (just most important):
1. Buyer
   1.1. Select one or many products of the same or different types as one purchase;
   1.2. Insert coins before/during product selection or before purchasing finalization;
   1.3. Pay with either card or coins (only single method is allowed);
   1.4. Cancel purchasing and return money (coins) before finalize purchasing (obtain products in the product dispenser);

2. Business:
   2.1. Connect to service functionality (authentication);
   2.2. Add/Append/Remove products in slots;
   2.3. Change product unit cost;
   2.4. Get full accounting information from the last connection;

3. Machine:
   3.1. Return over-payment if more coins spent for purchasing;
   3.2. Automatically exclude a product from the possibility to select if the appropriate slot is empty.

Task: Provide UML static and dynamic model for the Vending machine

The lift system description
There are several lifts in the building.

Call a lift To call lift, a passenger have to use the control panel (Pic1) which is located on every floor.
There are can be single or multiple panels per floor.

To request a lift just enter the destination floor number (Pic2). E.g. 12.
Then the lift system will show which lift is going to deliver you to the required floor (Pic3).
Here lift B which is at right of this panel.
After short pause, the panel is cleared and is ready for next request.

There is a limitation on the weight of passengers in a cabin.
For simplification, lets suppose each cabin can contains no more than 5 passengers.
If there are more passengers waiting the same lift, then the rest have to call lift again.

Lift cabin
Inside the lift cabin there is no any control to point floor.
Just indicator with the 2 next stops (Pic4). Here the neares stop is floor 9, and the next is floor 15.

Lift cannot make a stop earlier than those two floors at the indicator.
For example, lift goes down from floor 24 and idicators show 20,15.
All floors after the second stop, can be added for making a stop.
If so, then the lift cannot make a stop at any floor before 20 (23,22,21) and also between 20 and 15(19,18,17,16).

Task 1
  Design the lift system.

• The building contains 4 lifts.
• Each floor contains 2 control panels to call lifts (between lifts and opposite each other).
• The model should include all lift system components + passenger(s).
• Language: UML

Task 2
  Implement the lift system + modeling its work in realtime (run the model).

• The building contains 4 lifts - A B C D.
• Each floor contains 2 control panels to call lifts (between lifts and opposite each other).
  For the modelling purposes, you can use them in parallel or just use one panel with single thread/process.
• Number of floors is 24.
• Max number of passengers per cabin is 5.
  If more passengers are sheduled to the same cabin, then the rest should call lift again.
• Imitate passengers flow direction and intensity depending on the day time.
  E.g. 7-9am - most of passengers travel from floor 1 to other floors (intensivity is high),
  and quite few between floors (intensivity is low).
  9am-4pm - most of passengers travel between floors (intenivity is low).
  from 4pm - all passengers travel to floor 1 until no one leave in the building (intensivity is high).
  The number of passenger should be quite big to demonstrate the model.
• The lift control system should optimize the usage of the lifts to bring higher throughput.

• The imitation model should be separated from the implemented lift system.
• The implementation should provide the ability to change all significant constants.
  E.g. number of cabins, number of floors, max passengers per cabin and so on.
• For simplification, every passenger have to call a lift (no group per one call).