[TIL] 디자인패턴과 네트워크 팀스터디 (24.01.12 - 21일차)

학습내용

---

팀스터디

---

디자인패턴

• 🏭팩토리메서드🏭

  정의

  객체의 생성코드를 별도의 클래스로 분리하는 방식이다.

  실질적인 구현은 하위클래스가 결정하도록 위임하는 디자인패턴

  특징

  • 템플릿메서드에서 파생된 것이라고 한다. (목적만 다르고 형태는 같음.)
  1. 상위클래스가 하위클래스의 로직을 알필요X 사용가능 => 유연성증가
  2. 단일 책임 원칙.
  • 객체 생성과 관련된 로직을 별도로 분리 ⇒ 하나의 책임만 지게 함.
    • 객체생성로직을 바꿔야한다하면 => 그 부분만 바꾸면됨. 상위클래스까지 건드릴필요X => 유지보수하기 좋다.

  3. 개방/폐쇄 원칙.

     ⇒ 또 새로운 객체 뭐 중형차가 필요하다면 기존 클래스의 코드를 변경하지 않고 확장이 가능하다.

  상위클래스 Factory는 MakeCar라는 추상메서드를 정의함.

  이 메서드의 구체적인 구현은 하위클래스에서.

  ⇒ Factory 클래스의 MakeCar()로 모든차를만들수있다. ⇒ string으로 승용차, 버스, 스쿠터

  ⇒ Car 인터페이스의 추상메서드인 Drive()를 또 각 차종들이 구현하므로

  차종에 맞게 메서드 오버라이딩 할 수 있다.

  // 객체를 생성할 Factory 클래스
  public class Factory {
      // 객체를 생성할 팩토리 메서드
      public Car MakeCar(String s) {
          if (s == "승용차") {return new SmallCar();}
          if (s == "버스") {return new Bus();}
          if (s == "스쿠터") {return new Scooter();}
  
          return null;
      }
  }

  장점:

  1. 느슨한 결합
     => 클래스 생성과 사용의 처리를 분리. 시스템의 다른 부분에 영향X. ⇒ 유지보수하기 쉬워짐

     단점 : 새로운 자식 클래스를 도입해야하므로 코드가 더 복잡해질수있다.

     해결책? => 생성 클래스들의 기존 계층구조에 패턴을 도입하는것

     ⇒ 추상 팩토리 패턴을 도입하여 관련 객체군을 생성하는 공통 인터페이스.

     팩토리 메서드 활용

  • 왜?? 생성자 코드는 따로 나머지 사용하는 코드와 독립적으로 확장하기 쉬워진다.

DHCP (Dynamic Host Configuration Protocol)

DHCP: 인터넷에 접속하는 컴퓨터에 일정기간동안 여러정보를 할당하는 프로토콜

⇒ 여러 정보라 하면, 네임서버주소, IP주소, 게이트웨이주소를 할당.

장점

• PC의 수가 많아도 자동으로 ip설정을 해주기 때문에 효율적으로 사용 가능
• IP 충돌 막을 수 있다.

단점: DHCP 서버에 의존성이 높아 서버에 이슈생기면 ip할당에 문제 생긴다.

DHCP는 IP 주소를 할당하고 관리하는 역할,

공유기는 이러한 DHCP 서비스를 제공하고 네트워크 트래픽을 관리하는 중추적인 역할

DHCP vs NAT

DHCP는 할당의 개념 (동적으로 할당)

NAT은 매핑의 개념 (주소변환)

공유기

: 라우터의 많은 기능중 NAT 기능을 첨가한것이 공유기

• 통신사에서 받은 공인 IP를 가상IP 여러개로 할당
• WAN포트가 있고 LAN포트가 있는데 WAN에 연결해야할 선을 LAN포트에 꼽으면 DHCP기능이 꺼진채로 허브브릿지 처럼 동작한다. (여러개로 할당XX)
  

많은 현대 공유기들은 내장된 DHCP 서버를 갖고 있습니다. 이는 공유기가 네트워크에 연결된 모든 장치에 자동으로 IP 주소를 할당할 수 있게 해줍니다.

공인 IP : 업체에서 사용자에게 할당하는 IP

⇒ 공유기가 인터넷과 통신하도록 하는 역할을 하는 외부 IP주소

사설 IP : 내부 IP주소