기존 게시글
11/4일 OS & DB : https://gall.dcinside.com/programming/1515784
11/5일 NETWORK : https://gall.dcinside.com/programming/1517022
Topic 1: 객체지향객체지향 : 객체단위로 묶어서 설계에 중점을 둔 방향으로 가는 프로그래밍 방식이라고 생각함. 따라서 설계가 매우 중요하다.
- 객체지향을 통해서 얻을 수 있는 엔지니어링적 이점은 뭐가있을까?
- 본인의 설계 하에서 자신의 코드(논리) 모순이 일어나면 쉽게 알 수 있다.
- 예를들어서 private 접근 제어해놓고, 접근하려고 하면 컴파일러 에러가 난다.
- 실제 현실세계에 있는 모델(뼈대)만 구상하여서 비슷하게 코드로 구현할 수 있다.
- 다시말해 내 생각과 설계대로 코드 구현이 가능하다.
- 유지보수가 용이하다.
- 코드수정을 최대한으로 줄일 수 있다.
- 디버깅을 비교적 쉽게 할 수 있다.
- 객체지향의 특징
-
캡슐화
- 데이터 속성 + 데이터 처리 함수를 객체로 묶는것을 의미.
- 객체와 관련된 함수들은 모두 객체안에 들어가있음. + 접근제어자로 접근 권한을 구분함 (public, private)
- 결국, 객체외부와 객체내부가 정확하게 구분이됨. (내부객체가 외부객체로부터 독립적이 됨)
- 다시말해서, 외부가 내부의 상태를 변경하는걸 제한할 수 있고, 외부가 내부의 정보를 가져가는 방법을 한정 시킬 수 있음. 또한 외부입장에서도 객체간의 세부 내용을 알 필요 없이 그냥 getResult(), setName()같은것으로 객체가 설계한대로 객체 내용을 가져오거나 수정할 수 있음.
- 이렇게되면 인터페이스가 매우 간단해지고, 객체 내부를 수정할 수 있는 요인이 한정됨 ⇒ 디버깅도 간단해짐.
- 예를들어, 객체끼리 통신하는게 public method로만 통신되니까, 객체 통신중에 오류가 났다 하면 그 method() 로직으로부터 살펴보면서 디버깅 가능.
- 유지보수도 용이함.내부 객체의 result를 뽑는 함수인 getResult() 의 로직이 바뀌었다고 하더라도, 외부객체는 수정할거 아무것도 없음. 그냥 똑같이 getResult() 부르면됨.
-
추상화
- 한마디로 필수적인 뼈대만 요약하는 행위.
- 대표적으로 UI의 추상화는..
- 버튼이면 → bool isSwitchOn; 으로 추상화가 가능하고 Text Input 은 String inputVal;으로 추상화 가능함. 스위치를 누르는 행위는 function click() 으로 추상화를 할 수 있음.
- 뼈대만 요약하는 이유 :
-
여러가지 이유가 있지만, 다양한 객체를 이 뼈대 요약(= 추상화) 하나로 커버 할 수 있기 때문임. (다형성과도 연관)
-
그래서, 구체적인 객체 구현에 집중하지말고 뼈대를 정하고 뼈대에 맞게 구현하는게 좋음. 뼈대 하나에 커버할 수 있는 객체들도 많아지고, 개발자가 어떤 뼈대구조를 생각하는지 확실하게 보이고, 재사용도 많이 할 수 있고 등등..
-
추상화를 하는 레벨도 중요하다고 생각하는데,
- 예를들어서 아우디, 벤츠는 → "자동차" 라는 뼈대를 가진다고 생각하고 추상화 가능.
- 근데 아우디,벤츠 → "탈것" 으로 넓게 추상화하면 "리어카"같은 객체도 이 뼈대 구분안에 들어감.
- 아우디,벤츠 → "수입차"로 추상화했으면 "현대차" 조차도 이 추상화안엔 못들어감.
-
추상화에 대한 이모저모 이야기 :
- UI 추상화를 최대한 피하기로 한 '뱅크샐러드' 팀의 의사결정과정과 Product Language 개발 관련 아티클:
-
-
상속성
- 이미 정의된 상위 클래스를 자식 클래스가 물려받을 수 있음.
- 코드량을 줄여줌.
- 그리고 관계도 명확하게 세워줄 수 있음.
-
다형성
- 서로 다른 클래스가 같은 동작명령을 받았을때 각자의 방식으로 동작하는 경우를 말함.
- 정의가 이해하기 어려울 수 있는데, 다시 설명하자면 객체지향에서 현재 내가 타입으로 정하고있는 그 클래스라고 할지라도, 각 객체마다 동작을 다르게 할 수 있음..
- 다시말해 "내가 타입으로 정하고 있는 그 클래스" 는 여러 객체들을 포함하는 역할만 하고 + "각 객체마다 동작을 다르게 하는것" 은 각 객체가 하고싶은대로 출력함.
- 서로 다른 객체를 하나의 기준 (추상화 [인터페이스, 상속]) 으로 묶을 수 있고 + 객체마다 동작결과는 다르게 만들 수 있음 그 라는게 포인트.
-
-
프로세스와 스레드의 차이(Process vs Thread)
- 프로세스 : 메모리에 올라와 실행되고 있는 프로그램.
- 쓰레드 : 프로세스 내에서 실행되는 여러 흐름의 단위.
- 프로세스 특 : 각 프로세스는 독립적으로 실행되며, Code, heap, data, stack 다 독립적으로 가지고 있음. 최소 1개의 쓰레드를 가지고 있음. 프로세스끼리의 통신은 조금더 까다로움.
- 쓰레드 특 : Code, Heap, Data 영역은 공유함. Stack만 각각 가지고있음. 그래서 프로세스 내에서 쓰레드 통신은 쉬움. 그리고 다른 쓰레드도 지금 내 쓰레드의 변경사항을 볼 수 있음. (그래서 동시성에 대한 고려를 해야함)
-
[보충] 사용자 수준 스레드와 커널 수준 스레드 비교.
-
커널 레벨 스레드 : 커널에 있는 스레드. OS라는 프로세스의 쓰레드 + CPU 활용.
-
사용자 레벨 스레드 : 유저 프로세스 안에서 유저가 임의로 만드는 쓰레드들.
-
커널 레벨 스레드가 맵핑을 하는 방법
- 퓨어 유저 레벨 : 커널 스레드 1개당 "프로세스" 1개 맵핑.
- 퓨어 커널 레벨 : 모든 유저 스레드와 모든 커널 스레드가 1:1로로 맵핑함.
- 컴바인드 : 두개의 장점을 합친것.
-
장단점
-
커널레벨스레드가 Pure user level로 맵핑을 하면,
- 유저 쓰레드가 100개 있어도 어처피 1개있는걸로 인식함.
- 커널 쓰레드는 오버헤드가 많이 발생하는데, 유저 쓰레드가 아무리 많아도 1개만 쓰므로, os 시스템 콜 오버헤드가 적음.
- 다만, 유저 쓰레드 안에서 한 쓰레드가 락을 걸면, 그 프로세스는 전체가 락이걸린것과 똑같음.
-
커널레벨스레드가 pure kernel-level로 맵핑을 하면,
- 유저 쓰레드 한개당 커널 쓰레드 한개가 배정됨.
- 그리고 멀티 프로세서에 스케줄러에 직접 등록되므로, 병렬처리에 매우 유리함. 프로세스에 하나가 락걸려도 다른 하나는 독립적으로 다른 프로세서에 배정되어서 수행됨.
- (스케줄링 동기화, 시스템콜 사용자모드-커널모드 전환 등 ) 오버헤드 많이 발생, 효율성 똥.
-
멀티 프로세스 대신 멀티 스레드를 사용하는 이유
- "동시성"에 대해서
- 무어의법칙 : 반도체 집적회로의 성능이 24개월마다 2배로 증가한다는 소리임.
- CPU 트렌드는 2000년 이후 성능증가폭은 줄고 코어증가폭만 늘어남.
우리의 목표 : 멀티코어를 최대한 활용하기.
-
- 프로세스 많이 써서 멀티코어 활용하자.
- 프로그래밍 어렵고 까다로움.
- 커뮤니케이션할때 오버헤드 많이나옴
- 컨텍스트 스위칭 비용이 비쌈.
-
- 프로세스 대신 쓰레드를 쓰기.
- 프로그래밍 간단함.
- 오버헤드 적음.
- 커뮤니케이션도 쉬움.
- ⇒ 멀티쓰레드 프로그래밍 선호.
동시성과 lock에 대한것도 쓰려고했는데
생각보다 내가 잘못이해하고 있는게 많았네요.
공부하고 내일 씁니다.
객체지향 세줄읽고거름ㅋㅋ
난 스크롤 길이보고 - dc Cpp
틀린거있으면 피드백부탁합니다~
확장성있는 코드를 위해~한다 한두마디면되는데 ㄹㅇ 빙빕이빙
인정 ㅋㅋ
근데 최대한 내가 이해하는만큼 자세하게 적어보고싶었음.. 남들이 내 틀리게 이해하는 부분도 캐치할 수 있고..
면접질문답변)위키복붙