생각대로 살지 않으면 사는대로 생각한다.

 이 포스팅은 EBS 라디오 "잉글리시 클리닉"의 방송내용을 바탕으로 원문 스크립트를 공부하고 녹음해서 한 주에 자기가 공부한 내용을 올리는 일종의 로그개념의 포스팅입니다. 혼자하기 힘드신 분들은 여기에서 본인이 녹음한 파일을 공유해서 같이 공부할 수 있는 공간이 되었으면 합니다.

회화가 초급이신 분들은 EBS 라디오 "잉글리시 클리닉"으로 시작해도 좋은거 같습니다. 회화 내용도 간단하고 설명도 재미있게 해주셔서 웃으면서 영어공부를 할 수가 있습니다.

+아래는 제가 녹음한 파일입니다.(음량을 줄여주세요)

[월요일]

A :  I lost my passport. What am I supposed to do? 

 여권을 분실했어요, 어떻게 해야 하나요?

B : You should visit the nearest police station and file a report.

 가장 가까운 경찰서를 방문해 (분실) 신고서를 제출해야 해요.

A : Is that all? 그렇게만 하면 되나요?

B : No, you should go to your embassy and apply for a new passport.

아뇨, 대사관에 가서 새로운 여권을 신청해야해요.

A : O.K. I will. Thank you. 

 감사합니다.

[화요일]

B : I lost my passport and I want to apply for a new one.

A : You are required to submit 2 passport photos. 

B : Here they are. 

A : O.K. And do you remember the issue date and the expiration date?

 발행일과 만료일을 기억하시나요?

B : I have a copy of my old passport.

 옛 여권의 복사본을 가지고 있어요.

A : Good. Can you let me see it? 

 좋습니다. 제게 주시겠어요?

[수요일]

A : Good afternoon! Where are you flying to today?

 안녕하세요! 오늘 (비행기로) 어디 가실 예정인가요?

B : Vienna.비엔나요

A : May I have your passport, please?

 여권 줘 보시겠어요?

B : Here you go. Say, would I be able to get an aisle seat? 

 여기요. 그런데, 복도 쪽 좌석으로 주시겠어요?

A : Sure. No problem. 

 네 알겠습니다.

B : Thank you. I may have to go to the washroom often. 

 감사합니다. 화장실에 자주 갈 일이 생길지 몰라서요.

[목요일]

A : Please lay your bags on the conveyor belt and walk through the detector.

 당신의 가방을 컨베이어 벨트 위에 올려두시고, 감지기를 통과해주세요.

B : O.K. 네

A : Step back, please! Do you have anything metallic in your pockets?

B : Oh, sorry! Do I have to take my cell-phone out of my pocket?

 호주머니의 제 핸드폰을 꺼내야 할까요?

A : Yes, please. Now come on through. You’re all set! Have a nice flight. 

네 그래주세요. 자 , 지나가세요. ... 됐습니다~ 즐거운 여행 되세요.

[금요일]

A : Welcome to Austria. Where are you from? 

 오스트리아에 온신 걸 환영합니다. 어디서 오셨어요?

B : I’m from Korea. 한국에서 왔어요

A : And what's the purpose of your visit to Austria?

 방문 목적이 무엇인가요?

B : I'm here for sightseeing. 

 관광차 여기 왔습니다.

A : How long do you plan to stay in Vienna? 

 빈에는 얼마나 오랫동안 체류할 계획입니까?

B : Just one week. 딱 한 주만 있을 거예요.

A : Where will you be staying?

 어디서 머무를 거에요?

B : I’m staying at a hotel. 

 호텔이요.

A : O.K. Enjoy your visit!

 즐거운 여행 되세요.

B : Thank you. 감사합니다.

2부 <영화 감독 조원희의 명장면 명대사>

오늘의 영화 : 노팅힐 -로저 미첼 감독, 1999년 작

1. 조원희가 뽑은 <노팅힐>의 첫 번째 명장면!

휴 그랜트와의 대화가 아니라, 서점에서 책을 훔치려던 도둑과의 대화.

https://youtu.be/ArlsU2_cUbg

2. 조원희가 뽑은 <노팅힐>의 두 번째 명장면!

일명 ‘브라우니’ 대결 장면

https://youtu.be/PTjIRQU_HdM

마지막 남은 브라우니를 놓고 등장인물들이 자기가 왜 불행한지 말해서 

1등 불행러가 브라우니를 차지하기로. 다들 이혼했다. 장애가 있다 등 자신들의 불행을 전시하는데...

안나의 차례가 되자 안나 왈:

Anna Scott: I've been on a diet every day since I was nineteen, which basically means I've been hungry for a decade. I've had a series of not nice boyfriends, one of whom hit me. Ah, and every time I get my heart broken, the newspapers splash it about as though it's entertainment. And it's taken two rather painful operations to get me looking like this.

Honey: Really?

Anna Scott: Really. And, one day not long from now, my looks will go, they will discover I can't act and I will become some sad middle-aged woman who looks a bit like someone who was famous for a while.

Max: [long pause] Nah, nice try gorgeous, but you don't fool anyone.

William: Pathetic effort to hog the brownie.

3. 조원희가 뽑은 <노팅힐>의 세 번째 명장면!

기자회견 장면. https://youtu.be/CC4wChOQKQ8

기자:  How long will you be intending to stay here, In Britain?

안나: Indefinitely

객체지향 개발 5대 원리 SOLID

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

 : HERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.

 클래스를 변경하는 이유는 단 하나의 이유여야 합니다. 클래스에 여러가지의 기능이 포함되어 있다면 클래스를 분리해서 새로운 기능을 사용하는 클래스를 만들어야 합니다. 

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

: YOU SHOULD BE ABLE TO EXTEND A CLASSES BEHAVIOR, WITHOUT MODIFYING IT.

 확장(상속)에는 열려있고 변경하는것에는 닫혀있어야 한다. 공통된 기능을 추상화해서 상위단계로 올려서 인터페이스나 추상객체를 만들고 하위에서는 그것을 상속받거나 구현해서 목적에 맞게 상세한 기능을 구현한다. 프로그램은 최대한 추상화된 클래스를 사용함으로써 신규 하위클래스나 변경에 종속되어서는 안된다. 변경될것과 변하지 않을 것을 구분해서 변하는 것을 인터페이스로 정의하고 하위 클래스에서는 인터페이스를 구현한다.

3. LSP (리스코브 치환의 원칙: The Liskov Substitution Principle) 

:FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.

 서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다

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

 : CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE.

 ISP원리는 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원리입니다.

5.DIP (의존성역전의 원칙: Dependency Inversion Principle)

 -A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.

 -B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS.

첫째, 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다. 둘째, 추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다.

 객체 지향 프로그래밍에서 의존 관계 역전 원칙은 소프트웨어 모듈들을 분리하는 특정 형식을 지칭한다. 이 원칙을 따르면, 상위 계층(정책 결정)이 하위 계층(세부 사항)에 의존하는 전통적인 의존 관계를 반전(역전)시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다.  

1. 파레토 법칙 (Pareto principle) 

  : 80 대 20 법칙, 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상

    (80% of the time spent on a software project is invested in 20% of the functionality.)

  소프트웨어의 개발 80%를 20%의 기능을 개발하는데 소비한다. 프로그램 사용자의 20%가 80%의 부하를 발생시킨다. 등으로 사용이 된다. 프로젝트를 설계할 때 이 법칙을 감안해서 설계를 하면 프로젝트를 위험에 빠트리게 하는 위험요소들을 사전에 파악하고 관리가 가능할 것이다. (예를 들어서 중요한 기능을 먼저 구현하던지 특정 사용자들에게서 집중적으로 자원이 소모되는 것을 감안해서 설계 하고 테스팅한다.)

2. 디미터 법칙 (The Law of Demeter)

:디미터 법칙은 객체 O의 메소드 m은 다음의 객체들의 타입의 메소드만 호출해야 한다는 법칙이다.

1. O 객체 자신의 메소드들. (O itself)

2. m의 파라미터로 넘어온 객체들의 메소드들.(M's parameters)

3. m 안에서 생성 되거나 초기화된 객체의 메소드들.(Any objects created/instantiated within M)

4. O객체의 직접 소유하는 객체의 메소드들.(O's direct component objects)

5.O객체의 m에서 접근이 가능한 전역변수의 메소드들.(A global variable, accessible by O, in the scope of M)

class Demeter {

    private A a;

    private int func() { return 0; }

    public void example(B b) {
        C c = new C();
        int f = func(); // 1번의 경우
        b.invert(); // 2번의 경우
        a = new A();
        a.setActive(); // 3번의 경우
        c.print(); // 4번의 경우

        // Static으로 설정된 Setting 변수가 있다고 가정할때.
        string UserID = GlobalValues.Setting.getUserID(); //5의 경우
    }
}

 위의 종류에 해당하는 객체의 메소드들만 호출을 해야한다. 그렇지 않으면 유지보수 측면에서 문제점들이 발생한다. 아래의 예를 보면,

objectA.getObjectB().doSomething(); 

objectA.getObjectB().getObjectC().doSomething(); 

 이렇게 호출을 하면 안된다.(보통 많이 하지만..) 이렇게 구현이 되면 사용하는 클래스의 메소드는  ObjectA가 변경이 되었을때만 코드를 수정하거나 고민해야 하는것이 아니라 ObjectB,ObjectC의 변경에도 모두 검토가 필요하다. 즉, 이런식으로 호출하면 ObjectB에만 노출되어야 할 메소드들이 ObjectA에게도 노출이 된다. 이런경우에 ObjectB,ObjectC의 doSomething에서 문제가 발생하면 ObjectA, ObjectB, ObjectC에 모두 영향을 미치게 된다. 최대한 노출 범위를 제한해서 유지보수가 쉽게 해야한다.

3. 콘웨이 법칙(Conway’s law)

 : 코드 구조는 개발팀의 구조를 따라간다는 법칙. 

(organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations)

 예를 들면, 컴파일러를 네개의 그룹에서 만든다면 컴파일러는 네 단계로 구성된다.  이것은 어떻게 보면 당연한 결과인데, 팀의 구조다 다르면 콤포넌트로 분리되서 서로 인터페이스로 연계가 된다. 이것에는 장단점이 존재하게 되는데 적절한 수준에서 구조를 정리하고 팀이 분리되어 있더라도 통합이 필요한 것은 통합을 해서 적정수준으로 코드구조를 관리해야한다.

<참고사이트>

https://en.wikipedia.org/wiki/Law_of_Demeter

http://alvinalexander.com/java/java-law-of-demeter-java-examples

https://en.wikipedia.org/wiki/Conway%27s_law