I am working on a software assignment where the design is component based. The components have ports which provide interfaces.
My professor argues that the Port class which is exposed by each component should be a Singleton, as the port must be the only way to interact with the component. As I see it, multiple instances don’t interfere with the requirement that the port must be the single interaction point.
Is as singleton the right way to implement a Port to the component?
To give an example:
The assignment is a model of an airplane and an airport. The components are different parts of an airplane and the airport. As it is a group assignment, different students have to implement different components.
This is the UML diagram of the different components of the airport: 
The interfaces are implemented in a class named Port, which is an inner class to the actual implementation. The outer class has a public field port and is a singleton. The different components interact by loading the Jar-File and accessing the Port instance via reflection.
13
Can the port of a UML component only be a singleton?
According to https://www.uml-diagrams.org/port.html UML does have notation to indicate multiple instances of a port, as well as multiple interfaces to a port.
Multiplicity of a port (if any) is shown after the port name in square brackets. Both name and multiplicity of port are optional.
Library Services class has 1 to 6 searchPort ports.
In UML diagrams, you will most likely see the majority of diagrams with one port. From a logical perspective, this is correct. From an implementation perspective, it shouldn’t matter.
Logically, you are connecting to one instance of a component that exposes functionality on the port. In real life there may be multiple instances of the same component and you only care about the interaction with one of them.
4
Singelton as a concept
Yes, since the port is a limited resource there should be only one object at runtime (a singleton) interacting with it. It should handle concurrent access of other components to that port.
So your application should create only one instance of the “PortHandler”.
Singelton as Code pattern
Often the logical singelton as described above is realized in code using the Singelton Pattern (private constructor and static accessor method)
This should be avoided.
The reason is that this static access makes your code tight coupled and therefore hard to reuse and in consequence hard to test. Also this “code supported singeltons” are merely a global variables which are known being evil almost since the beginning of programming…
e.g.: if you want to unittest your code interacting with the “PortHandler” you might want to replace the real “PortHandler” with a test double which you can programmatically configure to produce well defined data for your tested code.
If your Code under test gets the “PortHandler” via the static accessor method of the Singelton Pattern it is hard to replace.
If you pass the “PortHandler” in via dependency injection (using a DI framework by any chance) replacing it for testing is easy…