chatService

<옵저버 패턴?>

 

 

 

<직렬화>

 

 

 

 

<DTO 에 implements Serializable 하는 이유?>

• Serializable은 객체를 직렬화(Serialization) 하기 위해 사용돼요.
• 직렬화는 객체를 바이트 스트림으로 변환하는 과정이에요. 이렇게 하면 객체를 파일에 저장하거나 네트워크로 전송할 수 있어요.

왜 필요한가?

• 채팅 프로그램에서는 서버와 클라이언트가 객체를 주고받아야 해요.
• 예를 들어, 클라이언트가 ChatDTO 객체를 서버로 보내고 싶을 때, 이 객체는 네트워크를 통해 전송되어야 합니다. 그런데 네트워크는 바이트 단위로만 데이터를 전송할 수 있어요.
• 그래서 객체를 바이트로 바꿔서 보내야 하고, 이 과정을 **"직렬화"**라고 해요.

 

ObjectInputStream과 ObjectOutputStream의 역할

1. ObjectOutputStream (writer)
   • 객체를 직렬화하여 네트워크로 전송할 때 사용.
   • 서버가 클라이언트에게 메시지를 보낼 때 writer.writeObject()로 데이터를 전송
2. ObjectInputStream (reader)
   • 네트워크로부터 전달된 객체를 역직렬화하여 읽어올 때 사용.
   • 클라이언트가 서버에 보낸 데이터를 reader.readObject()로 읽어옴.

 

왜 writer를 먼저 생성하는가?

• ObjectInputStream과 ObjectOutputStream을 사용할 때 ObjectOutputStream을 먼저 열어야 해요.
• 이유는, ObjectInputStream이 스트림의 헤더를 먼저 읽으려고 시도하기 때문이에요.

📢 만약 reader를 먼저 생성하면?

• ObjectInputStream이 상대방의 헤더가 올 때까지 대기하게 돼서, **데드락(교착 상태)**이 발생할 수 있어요.
• 그래서 writer를 먼저 생성해서 헤더 정보를 먼저 전송해줘야 문제가 없어요.

 

 

 

<public class ChatDTO 와 class ChatDTO 차이 떄문에 나는 오류 >

 

• 패키지가 다르면 default 클래스는 직렬화에 문제
  • ObjectInputStream은 **패키지 이름 + 클래스 이름 + serialVersionUID**를 조합해서 직렬화된 데이터를 처리합니다.
  • 그런데, 한 쪽은 public이고 한 쪽은 default인 경우, 클래스 로딩이나 직렬화 과정에서 충돌이 발생할 수 있어요.
• serialVersionUID가 달라질 가능성
  • Java는 serialVersionUID를 명시하지 않으면 자동으로 생성합니다.
  • 클래스가 public인지 default인지도 이 값에 영향을 미칠 수 있어요.
  • 그래서 public과 default 클래스가 동일한 구조라도, 서로 다른 serialVersionUID가 자동 생성될 수 있음.
• 패키지 경로 인식 문제
  • public은 패키지와 상관없이 접근되지만, default는 패키지가 달라지면 서로 다른 클래스로 인식됩니다.
  • 서버와 클라이언트가 ChatDTO를 다르게 인식하게 되어 직렬화 오류가 발생하는 것.