Clase SSLSocketChannel.java , DefaultWebSocketServerFactory.java, DefaultExtension.java no cumple con el prinicipio Interface Segregation Principle #1428
En el repositorio de ‘Java-WebSocket’ en la clase ‘SSLSocketChannel.java’ en la línea 505 se implementa la interfaz WrappedByteChannel, lo provoca que la clase mencionada tenga que implementar el método writeMore(), aunque no lo necesite, lo cual da como resultado la violación al principio de Interface Segregation.
En el mismo repositorio ahora en la clase ‘DefaultWebSocketServerFactory.java’ se está implementando el método close() de la interfaz WebSocketServerFactory, lo cual viola el principio de Interface Segregation debido a que la clase en el que está no lo requiere.
Una solución viable es, en lugar de crear una clase que siempre retorne true, definir una interfaz que permita que las subclases determinen el comportamiento de las funciones. Alternativamente, se podría crear una clase abstracta con un método abstracto, de manera que las subclases implementan su propia lógica.
Solución Infracción 2:
En este caso, una posible solución sería utilizar el método super en la clase derivada para asegurar que funcione de manera consistente con la clase base. Esto permite que la clase derivada herede y respete la lógica definida en la clase padre, garantizando así un comportamiento uniforme.
Solución Infracción 3:
Primero convertimos el método onMessage a abstracto, luego creamos una nueva clase CustomWebSocketServer que extienda de WebSocketServer y allí implementamos el método onMessage
Interface Segregation Principle
https://github.com/TooTallNate/Java-WebSocket/blob/master/src/main/java/org/java_websocket/SSLSocketChannel.java
En el repositorio de ‘Java-WebSocket’ en la clase ‘SSLSocketChannel.java’ en la línea 505 se implementa la interfaz WrappedByteChannel, lo provoca que la clase mencionada tenga que implementar el método writeMore(), aunque no lo necesite, lo cual da como resultado la violación al principio de Interface Segregation.
https://github.com/TooTallNate/JavaWebSocket/blob/master/src/main/java/org/java_websocket/server/DefaultWebSocketServerFactory.java
En el mismo repositorio ahora en la clase ‘DefaultWebSocketServerFactory.java’ se está implementando el método close() de la interfaz WebSocketServerFactory, lo cual viola el principio de Interface Segregation debido a que la clase en el que está no lo requiere.
https://github.com/TooTallNate/Java-WebSocket/blob/master/src/main/java/org/java_websocket/extensions/DefaultExtension.java En la clase DefaultExtension.java del mismo repositorio, a los métodos decodeFrame(Framedata inputFrame), encodeFrame(Framedata inputFrame) y reset() no se les coloca un comportamiento específico, y debido a que la clase los implementa de la interfaz IExtension no los necesita se viola el principio de Interface Segregation.
Posibles Soluciones
Una solución viable es, en lugar de crear una clase que siempre retorne true, definir una interfaz que permita que las subclases determinen el comportamiento de las funciones. Alternativamente, se podría crear una clase abstracta con un método abstracto, de manera que las subclases implementan su propia lógica.
Solución Infracción 2: En este caso, una posible solución sería utilizar el método super en la clase derivada para asegurar que funcione de manera consistente con la clase base. Esto permite que la clase derivada herede y respete la lógica definida en la clase padre, garantizando así un comportamiento uniforme.
Solución Infracción 3: Primero convertimos el método onMessage a abstracto, luego creamos una nueva clase CustomWebSocketServer que extienda de WebSocketServer y allí implementamos el método onMessage