객체지향 설계 원칙, 트랜잭션 격리, 해쉬테이블

객체 지향 설계 원칙인 SOLID 원칙에 대해서 설명해주세요. 예시를 들어주세요.

객체지향 프로그래밍을 할때 지켜야할 5대 원칙을 말한다.

 

1. SRP(Single Responsibility Principle) 단일 책임의 원칙

• 하나의 클래스은 하나의 책임(기능)을 가져야 한다는 것

예시)

어떤 자동차 클래스가 있는데, 엔진, 히터 등등 복잡한 시스템이 있다
class car {
   // 여기에 모두 넣어버리면 복잡해짐
  seat : 다른 클래스 불러옴(쪼갬)
  heater : 다른 클래스 불러옴(쪼갬)
}
=> 이러한 복잡한 시스템을 여러개로 쪼개서 나누고 하나로 묶는 것

 

 

 

2. OCP(Open Close Principle) 개방 폐쇄의 원칙

• 확장에는 열려있고, 수정에는 닫혀있어야 한다는 원칙
• 확장 - 요구사항이 변경될때 새로운 동작을 추가하여 애플리케이션의 기능을 확장할 수 있다
• 수정 - 기존의 코드를 수정하지 않고 애플리케이션의 동작을 추가하거나 변경할 수 있다
• 추상화에 의존
  • 추상화? 핵심적인 부분만 남기고, 불필요한 부분 제거함으로써 복잡한 것 -> 간단히 하는것

예시)

class Animal {
 울기 () {  
   강아지 -> 멍멍
   고양이 -> 야용
   // 기능 추가   => 계속 추가하면 안됨!!!!!
    소 -> 음메   
    ...
 }
}

////////잘못된 방법
Animal a = new Animal("강아지"); 
a.울기();

/////////옳은 방법
Animal 클래스를 상속받는 강아지.class, 고양이.class .... 만든다
소라는 클래스 만들고 Animal 클래스 상속받기
Animal  a = new 강아지();
Animal a = new 소();
a.울기();

 

 

3. ISP(Interface Segregation Principle) 인터페이스 분리 원칙

• 목적과 관심이 각기 다른 클라이언트가 있다면 인터페이스를 통해 적절하게 분리해야함
• 클라이언트의 목적과 용도에 적합한 인터페이스 만을 제공하는 것
• 하나의 일반적인 인터페이스 보다는 여러개의 구체적인 인터페이스를 사용하는 게 좋다

예시)

Interface 동물 {
   짖기();
   걷기();
}

class 강아지 implements 동물 {
    짖기();
    걷기():
}

class 고양이 implements 동물 {
    //고양이는 짖기();가 필요없지만  인터페이스 받으면 짖기();도 같이 가져와야한다 
    걷기(); 
}


=> 그래서 짖기();용 인터페이스 따로   |    걷기();용 인터페이스 따로 여러개로 구분해서 분리해서 쓰는 것이 좋다!! 

 

 

 

4. LSP(Liskov Substitution Principle) 리스코프 치환 원칙

• 올바른 상속 관계 특징 정의
• 자식클래스는 언제나 부모클래스를 대체할 수 있도록 상속해야 한다는 원칙
  
  • 해당 객체를 사용하는 상위타입이 하위 타입으로 변경되어도, 차이점을 인식하지 못한채 상위 타입의 퍼블릭 인터페이스를 통해 서브 클래스를 사용할 수 있어야 함

 

예시)

class 로보트 {
   size = 10*10;
}
를 상속받는 
class AI로보트 extends 로보트 {
}
자식 클래스가 있는데
 
로보트 a = new Al로보트();
a.size = 10*10; 이어야지 다른 값이면 안된다!!

 

 

5. DIP(Dependency Inversion Priniple) 의존 역전 원칙

•  추상화에 의존하며 구체화에는 의존하지 않는 설계원칙
• 개방 폐쇄 원칙과 밀접한 관련 있음 -> 2번
• 의존관계에서는 좀 더 추상화된 것을 의존하는 게 좋다

예시)

class 토끼 {
    ///이런식으로 쓰지말고
    //먹이 = carrot;
    // vegetable 데이터 타입 받아서 쓰는 것이 좋다 
    vegetable 먹이;
}

// 상위개념을 의존하는 게 좋다!!!
class vegetable { // 부모클래스
}

// 이런 하위 개념을 의존하지 말고
class carrot extends vegetable {  //상속받음
} 
class apple extends  vegetable {  //상속받음
} 

 

결국, 핵심은 추상화이다.
구체 클래스에 의존하지 않고 추상 클래스(or 인터페이스)에 의존함으로써 유연하고 확장 가능한 애플리케이션을 만들 수 있다는 것!!!

 

출처:

https://www.youtube.com/watch?v=KO2xdqOZSAs

트랜잭션 격리 수준별로 어떠한 문제가 발생할 수 있을까요?

경쟁 상태 (Race Condition)

- 여러 클라이언트가 같은 데이터 동시 접근할 경우 문제 발생

• 커밋되지 않은 데이터 읽기
• 커밋되지 않은 데이터 덮어쓰기

- 트랜잭션 격리(Isolation)

트랜잭션을 격리시켜서 다른 트랜잭션이 영향을 주지 못하게 하는것

- 가장 쉬운 방법은 트랜잭션을 순서대로 실행하는 것

  동시 접근 문제 아예없지만

   한 번에 한개 트랜잭션만 처리하므로 성능(처리량) 저하 가능

- 그래서 !! 문제 상황에 맞게 다양한 격리 수준 지원

• Read Uncommitted : 사실상 사용안함
• Read Committed : 커밋된 데이터만 읽음
  
  • 트랜잭션이 끝날때 까지 기다려야함
  • 읽는 동안 데이터 변경
• Repeatable Read : 트랜잭션 동안 데이터가 변경되더라도 같은 데이터를 읽게함
  • 변경한 내용이 유실될 수도 있다
• Serializable : 인덱스 잠금이나 조건 기반 잠금 등 사용
  • 잠금 시간이 길어지면 성능(처리량) 저하

 

 

출처:

https://www.youtube.com/watch?v=poyjLx-LOEU

 

 

해쉬 테이블은 무엇인가요? 해쉬값이 충돌하면 어떻게 해결할 수 있을까요?

 

 

해쉬테이블 Hasp map (=Hash Table)

• key-value 형태로 데이터를 저장하는 자료구조
• 하나의 key는 하나의 value에 맵핑
• key는 고유함

 

구현?

• 배열을 사용하여 구현
  • 배열의 크기와 상관없이 데이터의 상수시간으로 접근 가능
  • array[index%key] 로 값 구함 (모듈러 연산)

 

 

해쉬충돌?

 -> 절대 hashmap은 key 사이즈 만큼 잡지 않는다

      만약 key 사이즈 만큼 잡아버리면 메모리 낭비 발생!!

예) 5000만 국민 모두 서비스 사용안함 -> key 5000만개 만들어봤자 필요x -> 현실은 1000명만 쓰고 있어서 hashmap 사이즈는 1000개 로 만들어둔다

 

해결 방법?

 

 

 

출처

https://www.youtube.com/watch?v=tEOkPaZXGOk 

https://www.youtube.com/watch?v=dKqv1mQotNU