jasu's blog
블로그 메뉴글
남 캘리포니아대에서 개발한 360도 입체영상 디스플레이를 개발
User Interface/Etc
2007. 9. 2. 09:53
남 캘리포니아 대학의 연구자들이 360도 입체영상 디스플레이를 개발했다.이 디스플레이는 "holographic diffuser"라고 하는 특수 필름을 붙인 회전거울과 고속 프로젝터 DVI의 특수한 디코더를 통해 구성되어 있다고 한다. 아래 동영상에서 보면 흑백의 와이어 프레임 모형이나 다각형 모델, 실사 입체 모형도 표시할 수 있어서 컬러 표시도 가능하다고 한다.
이 holographic diffuser의 기술은 .세로 방향에는 난반사하지만 횡 방향에는 거의 난반사가 일어나지 않는다고 하는 특성을 이용하였다고 한다. 이를 통해서 입체영상을 표현 할 수 있고 본체에 대해서 앵글이 높거나 낮아도 상을 볼 수 있게 되어 있다.
논문 : http://gl.ict.usc.edu/Research/3DDisplay/3Ddisplay_preprint.pdf
이 holographic diffuser의 기술은 .세로 방향에는 난반사하지만 횡 방향에는 거의 난반사가 일어나지 않는다고 하는 특성을 이용하였다고 한다. 이를 통해서 입체영상을 표현 할 수 있고 본체에 대해서 앵글이 높거나 낮아도 상을 볼 수 있게 되어 있다.
논문 : http://gl.ict.usc.edu/Research/3DDisplay/3Ddisplay_preprint.pdf
글
[AS3] SelectArea, DrawShape and Sewing
Project/Programming
2007. 8. 31. 18:30
예전에 http://www.tileui.com/ 사이트를 보면 스테이지 상에 있는 복수의 오브젝트를 선택할 때 직사각형으로 선택하는 것이 아닌 draw 형태를 이용하여 필요한 요소만 선택할 수 있다. 이 것을 보고 그려진 Shape를 통해서 선택할 수 있도록 하면 되겠다 싶어서 구현해 봤다.
일단은 클래스의 구조는 아래와 같이 작성했다.
DrawShape.as
이 클래스는 Point 요소를 가지고 있는 Array를 전달하고 그것을 통해 그려진 Shape를 돌려주는 클래스
Sewing.as
이 클래스는 Point 요소를 가지고 있는 Array를 전달하고 그것을 통해 외각선을 그려주는 클래스
SelectArea.as
이 클래스는 DrawShape와 Sewing클래스를 통해 그려진 Shape에 걸쳐진 오브젝트들을 Array로 반환하는 메소드를 가지고 있다. 여기에는 마우스를 UP을 했을 때 Event를 dispatch하게 되는데 이벤트를 받는 메소드에서 기존의 array 요소 중에서 선택된 오브젝트 요소를 가지고 있는 새로운 배열을 참조할 수 있게 하였다.
아래 예제에서는 랜덤한 위치에 생성한 오브젝트들을 마우스 down and drag, up을 통해서 선택을 하면 대각선 방향으로 정렬하게 해놨는데 대각선으로 정렬되는 것은 일정한 규칙이 있는 것은 아니고 디테일하게 하기 귀찮아서 그냥 되는대로 정렬해놨다…쿠쿠 목적이 없는 예제는 슬슬 힘이 빠진다는..;;
일단은 클래스의 구조는 아래와 같이 작성했다.
DrawShape.as
이 클래스는 Point 요소를 가지고 있는 Array를 전달하고 그것을 통해 그려진 Shape를 돌려주는 클래스
Sewing.as
이 클래스는 Point 요소를 가지고 있는 Array를 전달하고 그것을 통해 외각선을 그려주는 클래스
SelectArea.as
이 클래스는 DrawShape와 Sewing클래스를 통해 그려진 Shape에 걸쳐진 오브젝트들을 Array로 반환하는 메소드를 가지고 있다. 여기에는 마우스를 UP을 했을 때 Event를 dispatch하게 되는데 이벤트를 받는 메소드에서 기존의 array 요소 중에서 선택된 오브젝트 요소를 가지고 있는 새로운 배열을 참조할 수 있게 하였다.
아래 예제에서는 랜덤한 위치에 생성한 오브젝트들을 마우스 down and drag, up을 통해서 선택을 하면 대각선 방향으로 정렬하게 해놨는데 대각선으로 정렬되는 것은 일정한 규칙이 있는 것은 아니고 디테일하게 하기 귀찮아서 그냥 되는대로 정렬해놨다…쿠쿠 목적이 없는 예제는 슬슬 힘이 빠진다는..;;
글
[OOP] 디자인 원리 - Head First-OOAD
Programming/Design Patterns
2007. 8. 28. 07:35
『Head First Object-Oriented Analysis&Design』 책의 내용 중에 8장에서 다루고 있는 디자인 원리에 관한 좋은 내용이 있어서 소개한다.
여담 : 여러분들 마우스 옆에 핸드폰 놓지 맙시다. 자꾸 헷갈리네…쿠쿠
일단 와 닫는 짧은 문장 하나, “모방은 바보 같은 짓을 하지 않기 위한 가장 진지한 방안입니다.” 이 이야기는 새롭고 독창적인 방법이 좋을 수 있으나 그 방법은 기존에 같은 문제를 해결한 것이 없거나 자신의 독창적인 방법이 나은 결과를 가져왔을 때만 유효한 해결책이라는 설명이다. 이런 비슷한 내용은 디자인 패턴 관련 책에서 주로 다루고 있는데 이미 입증된 것이 항상 옳은 방법일 수는 없으나 가장 안전한 방법일 듯 싶다.
디자인 원리 : 디자인 원리는 코드를 좀 더 유지보수하기 쉽고, 유연하고, 확장하기 쉽게 만들기 위해, 코드의 작성이나 디자인에 적용되는 기본 도구 또는 기법이다.
객체지향 원리
1. 변하는 것을 캡슐화하라.
2. 구현에 의존하기 보다는 인터페이스에 의존하도록 코딩하라.
3. 각 클래스는 변경 요인이 오직 하나이어야 한다.
4. 클래스는 행동과 기능에 관한 것이다.
위와 같은 디자인 원리에 대한 구체적인 내용을 살펴보면 아래와 같다.
원리 1)
개방-폐쇄의 원리 OCP(Open-Closed Principle)
클래스는 확장에는 열려 있고, 수정에는 닫혀 있어야 한다는 것으로 보통 추상클래스의 확장과 override 개념에서 찾을 수 있을 듯싶다. 추상 클래스(상위 클래스) 자체는 하나의 독립되고 완전한 기능을 수행하며 수정에 닫혀 있고 그 추상 클래스를 확장하는 클래스에서 개별적으로 필요한 기능은 오버라이드를 통해서 고유의 기능을 수행할 수 있도록 하는 개념을 의미한다.
Java에서는 파라미터의 형태, 파라미터의 개수, 메소드의 접근성이 다를 경우에는 전혀 다른 메소드로 인식할 수 있다. 이 때문에 private로 선언된 함수를 사용하되 그 함수와 다른 기능을 수행하는 같은 메소드명의 public 메소드를 새로 만들어 외부에서 접근할 수 있도록 하는 경우도 이 OCP원리에 부합되는 예라고 할 수 있다.
원리 2)
반복 금지의 원리 DRY(Don’t Repeat Yourself)
공통되는 부분을 추출하여 추상화하고 한 곳에 두어 중복 코드를 피하라는 내용이다. 책에서는 2장에서 설명한 강아지 문(외국의 전원주택을 보면 애완견이 스스로 출입할 수 있도록 현관문 아래에 작은 문을 달아놓은 것을 프로그래밍한 내용)에 대한 이야기로 개념을 설명하고 있는데 리모컨을 눌렀을 때 열려있던 문은 닫히고 닫혀있던 문은 여는 기능을 수행한다. 또한 문은 리모컨 뿐만이 아니라 강아지가 짖는 소리에도 열린다. 그리고 열려있던 문은 일정한 시간이 지나면 자동으로 닫게 설계되어 있는데 이때 일정한 시간이 흐르면 자동으로 닫히는 기능을 리모컨 기능에도 넣고 강아지가 짖는 것을 판별하는 기능에도 넣었을 때 코드가 중복되는 것을 강아지 문 하나에 넣어 문이 open 되었을 때 일정 시간이 지나면 닫히게 할 수 있다는 것이다. 강아지 문을 여는 행위를 지시하는 곳은 두 곳이지만 이 두 곳 모두 일정 시간이 지나면 자동으로 닫히는 기능을 넣는 중복을 피하고 그 행위를 하는 강아지 문에 기능을 넣는 것이 좋다는 것이다. 하나의 요구사항은 한 곳에 두어 코드 중복으로 인한 유지보수의 어려움을 없애야 한다는 내용이다.
원리 3)
단일 책임의 원리 SRP(Single Responsibility Principle)
시스템의 모든 객체는 하나의 책임만을 가지며, 객체가 제공하는 모든 서비스는 그 하나의 책임을 수행하는 데 집중되어 있어야 한다는 내용이다. 이는 얼핏 보면 반복 금지의 원리와 비슷하다고 볼 수 있는데, 반복금지의 원리는 SRP를 포괄하는 내용이라고 볼 수 있다. 반복금지의 원리는 하나의 기능을 한 곳에 두자는 내용으로 그 한 곳이 클래스가 될 수도 있고 코드가 될 수도 있다. 하지만 SRP는 클래스가 한 가지 일만 잘하게 하자는 내용이다.
책에서는 간단하면서도 재미있는 방법을 제한하고 있는데 아래와 같은 방법이다.
[*]이 자신을 [*]한다.를 한 줄에 하나씩 작성하고 첫 번째 빈칸에는 자신 클래스명을 기입하고 두 번째 빈칸에는 자신 클래스에서 사용하고 있는 메소드명을 기입하는 것이다. 이렇게 작성하여 한 줄씩 큰 소리로 읽어보면 ‘무엇이 자신을 무엇 한다’는 말이 맞지 않은 경우가 SRP를 위반할 가능성이 높다는 이야기다. 예를 들면 다음과 같다.
Automobile 이라는 클래스에 아래와 같은 메소드들이 있다고 가정하면
1. start()
2. stop()
3. changeTires(Tire[*])
4. drive()
5. wash()
6. checkOil()
7. getOil():int
1. [Automobile]이(가) 자신을 [start](출발한다).
2. [Automobile]이(가) 자신을 [stop](멈춘다).
3. [Automobile]이(가) 자신을 [changeTires](타이어를 간다).
4. [Automobile]이(가) 자신을 [drive](운전한다).
5. [Automobile]이(가) 자신을 [wash](닦는다).
6. [Automobile]이(가) 자신을 [checkOil](오일을 점검한다).
7. [Automobile]이(가) 자신을 [getOil](기름을 얻는다).
위와 같이 썼을 때 책에서는 3개의 메소드는 SRP를 따르고 있고 나머지 4개의 경우에는 SRP를 따르지 않고 있다고 이야기 하고 있다. 다시 말해서 3개의 메소드는 Automobile 클래스에 있어야 하지만 나머지 4개의 메소드는 따로 빼내어 다른 클래스로 만들어야 단일 책임의 원리를 따를 수 있다는 이야기다.
답은 며칠 후에 이 포스트에 추가로 올려놓도록 할 테니 여러분들도 한번 고민해 보고 어떤 것이 단일 책임의 원리를 위반하고 있다고 생각하는지 댓글을 남겨보면 좋겠다. 책에서는 SRP.는 단지 가이드라인일 뿐이지 꼭 이 방법을 따라야 한다는 것은 아니라고 설명하고 있다. 클래스의 기능과 프로젝트에 대한 상식, 그리고 경험을 통해서 디테일한 부분을 스스로 결정해야 한다고 설명하고 있으니 부담 없이 참여해 보시길…
원리 4)
리스코프 치환 원리 LSP(Liskov Substitution Principle)
자식 타입들은 부모 타입들이 사용되는 곳에 대체될 수 있어야 한다는 내용이다. 이는 잘 디자인된 상속에 관한 내용으로 부모 클래스를 상속할 때, 부모 클래스가 사용되는 곳은 아무 문제없이 자식 클래스도 사용할 수 있어야 한다는 것이다. 그렇지 않으면 상속을 잘못 사용하고 있다는 것.
예를 들어 Board라는 클래스는 대부분의 메소드에서 x와 y의 인자를 사용하지만 3DBoard 클래스의 경우는 x,y,z 인자를 사용한다. 이때 3DBoard 클래스가 Board 클래스를 상속하였을 때 3DBoard 클래스에서는 상속된 Board 클래스의 기능이 전혀 필요 없음에도 상속을 하는 경우이다.
이렇게 되었을 때는 상속을 통해서 얻는 것보다 잃는 것이 많아지는데 이는 불필요한 메소드와 구조상 가독성이 떨어지기 때문이다. 불필요한 상속을 피하고 LSP 따를 수 있는 방법으로는 아래와 같은 방법이 있을 수 있다고 설명한다.
1. 상속 보다는 연관을 사용한다
이것은 3DBoard에 Board 인스턴스를 가지고 있으며 Board를 사용하되 zpos 값을 통해서 3DBoard를 표현하는 방법이다.
2. 구성(Composition)을 사용하여 다른 클래스들의 행동을 조합한다.
이 방법은 하나의 인터페이스를 따르는 클래스들의 묶을 배열 형태로 저장하여 필요한 클래스를 동적으로 적용할 수 있는 방법이다. 구성의 경우 구성을 가지고 있는 클래스가 소멸했을 때는 그 클래스에 포함된 구성 요소들도 함께 소멸한다.
3. 집합(Aggregation)을 상용하여 구성에서 구성 요소들이 사라지지 않게 한다.
이 방법은 구성과 비슷하지만 구성 요소들이 외부에서도 사용할 수 있도록 하여 집합을 가지고 있는 인스턴스가 소멸했을 때에도 집합 요소들은 사라지지 않도록 하는 방법이다.
책에서는 LSP위한 방법으로 아래와 같이 정리하고 있다.
1. 위임(Delegation)
클래스의 행동을 변경하고 싶지 않고 그 행동을 스스로 구현하는 것이 그 클래스의 책임이 아닌 경우에는 그 행동을 다른 클래스에 위임(Delegation)한다.
2. 구성(Composition)
구성을 사용하여 하나 또는 여러 개의 클래스, 특히 비슷한 종류의 여러 클래스들로부터 행동을 재사용할 수 있다. 여러분의 객체가 다른 객체를 완전히 소유하고 있는 형태이며, 구성 관계로 연결된 객체는 여러분 객체의 외부에 독립적으로 존재할 수 없다.
3. 집합(Aggregation)
구성 관계의 이점을 바라지만 여러분 객체의 외부에서도 연결된 객체의 행동이 사용되는 경우, 집합을 사용한다.
덧붙여 책에서는 위임과 구성 그리고 집합을 상속보다 선호하면, 대개의 경우 소프트웨어는 더 유연하고, 유지보수성, 확장성, 그리고 재사용성이 좀더 좋아진다고 이야기 하고 있다. 꼭 그런 것은 아니겠지만 LSP를 따르지 않는 상속은 구조를 복잡하게 하고 재사용성이 떨어질 수 있기 때문이라고 할 수 있다. LSP를 따르는 상속의 경우에는 상속을 사용하는 것이 바람직할 것으로 생각된다.
여담 : 여러분들 마우스 옆에 핸드폰 놓지 맙시다. 자꾸 헷갈리네…쿠쿠
일단 와 닫는 짧은 문장 하나, “모방은 바보 같은 짓을 하지 않기 위한 가장 진지한 방안입니다.” 이 이야기는 새롭고 독창적인 방법이 좋을 수 있으나 그 방법은 기존에 같은 문제를 해결한 것이 없거나 자신의 독창적인 방법이 나은 결과를 가져왔을 때만 유효한 해결책이라는 설명이다. 이런 비슷한 내용은 디자인 패턴 관련 책에서 주로 다루고 있는데 이미 입증된 것이 항상 옳은 방법일 수는 없으나 가장 안전한 방법일 듯 싶다.
디자인 원리 : 디자인 원리는 코드를 좀 더 유지보수하기 쉽고, 유연하고, 확장하기 쉽게 만들기 위해, 코드의 작성이나 디자인에 적용되는 기본 도구 또는 기법이다.
객체지향 원리
1. 변하는 것을 캡슐화하라.
2. 구현에 의존하기 보다는 인터페이스에 의존하도록 코딩하라.
3. 각 클래스는 변경 요인이 오직 하나이어야 한다.
4. 클래스는 행동과 기능에 관한 것이다.
위와 같은 디자인 원리에 대한 구체적인 내용을 살펴보면 아래와 같다.
원리 1)
개방-폐쇄의 원리 OCP(Open-Closed Principle)
클래스는 확장에는 열려 있고, 수정에는 닫혀 있어야 한다는 것으로 보통 추상클래스의 확장과 override 개념에서 찾을 수 있을 듯싶다. 추상 클래스(상위 클래스) 자체는 하나의 독립되고 완전한 기능을 수행하며 수정에 닫혀 있고 그 추상 클래스를 확장하는 클래스에서 개별적으로 필요한 기능은 오버라이드를 통해서 고유의 기능을 수행할 수 있도록 하는 개념을 의미한다.
Java에서는 파라미터의 형태, 파라미터의 개수, 메소드의 접근성이 다를 경우에는 전혀 다른 메소드로 인식할 수 있다. 이 때문에 private로 선언된 함수를 사용하되 그 함수와 다른 기능을 수행하는 같은 메소드명의 public 메소드를 새로 만들어 외부에서 접근할 수 있도록 하는 경우도 이 OCP원리에 부합되는 예라고 할 수 있다.
원리 2)
반복 금지의 원리 DRY(Don’t Repeat Yourself)
공통되는 부분을 추출하여 추상화하고 한 곳에 두어 중복 코드를 피하라는 내용이다. 책에서는 2장에서 설명한 강아지 문(외국의 전원주택을 보면 애완견이 스스로 출입할 수 있도록 현관문 아래에 작은 문을 달아놓은 것을 프로그래밍한 내용)에 대한 이야기로 개념을 설명하고 있는데 리모컨을 눌렀을 때 열려있던 문은 닫히고 닫혀있던 문은 여는 기능을 수행한다. 또한 문은 리모컨 뿐만이 아니라 강아지가 짖는 소리에도 열린다. 그리고 열려있던 문은 일정한 시간이 지나면 자동으로 닫게 설계되어 있는데 이때 일정한 시간이 흐르면 자동으로 닫히는 기능을 리모컨 기능에도 넣고 강아지가 짖는 것을 판별하는 기능에도 넣었을 때 코드가 중복되는 것을 강아지 문 하나에 넣어 문이 open 되었을 때 일정 시간이 지나면 닫히게 할 수 있다는 것이다. 강아지 문을 여는 행위를 지시하는 곳은 두 곳이지만 이 두 곳 모두 일정 시간이 지나면 자동으로 닫히는 기능을 넣는 중복을 피하고 그 행위를 하는 강아지 문에 기능을 넣는 것이 좋다는 것이다. 하나의 요구사항은 한 곳에 두어 코드 중복으로 인한 유지보수의 어려움을 없애야 한다는 내용이다.
원리 3)
단일 책임의 원리 SRP(Single Responsibility Principle)
시스템의 모든 객체는 하나의 책임만을 가지며, 객체가 제공하는 모든 서비스는 그 하나의 책임을 수행하는 데 집중되어 있어야 한다는 내용이다. 이는 얼핏 보면 반복 금지의 원리와 비슷하다고 볼 수 있는데, 반복금지의 원리는 SRP를 포괄하는 내용이라고 볼 수 있다. 반복금지의 원리는 하나의 기능을 한 곳에 두자는 내용으로 그 한 곳이 클래스가 될 수도 있고 코드가 될 수도 있다. 하지만 SRP는 클래스가 한 가지 일만 잘하게 하자는 내용이다.
책에서는 간단하면서도 재미있는 방법을 제한하고 있는데 아래와 같은 방법이다.
[*]이 자신을 [*]한다.를 한 줄에 하나씩 작성하고 첫 번째 빈칸에는 자신 클래스명을 기입하고 두 번째 빈칸에는 자신 클래스에서 사용하고 있는 메소드명을 기입하는 것이다. 이렇게 작성하여 한 줄씩 큰 소리로 읽어보면 ‘무엇이 자신을 무엇 한다’는 말이 맞지 않은 경우가 SRP를 위반할 가능성이 높다는 이야기다. 예를 들면 다음과 같다.
Automobile 이라는 클래스에 아래와 같은 메소드들이 있다고 가정하면
1. start()
2. stop()
3. changeTires(Tire[*])
4. drive()
5. wash()
6. checkOil()
7. getOil():int
1. [Automobile]이(가) 자신을 [start](출발한다).
2. [Automobile]이(가) 자신을 [stop](멈춘다).
3. [Automobile]이(가) 자신을 [changeTires](타이어를 간다).
4. [Automobile]이(가) 자신을 [drive](운전한다).
5. [Automobile]이(가) 자신을 [wash](닦는다).
6. [Automobile]이(가) 자신을 [checkOil](오일을 점검한다).
7. [Automobile]이(가) 자신을 [getOil](기름을 얻는다).
위와 같이 썼을 때 책에서는 3개의 메소드는 SRP를 따르고 있고 나머지 4개의 경우에는 SRP를 따르지 않고 있다고 이야기 하고 있다. 다시 말해서 3개의 메소드는 Automobile 클래스에 있어야 하지만 나머지 4개의 메소드는 따로 빼내어 다른 클래스로 만들어야 단일 책임의 원리를 따를 수 있다는 이야기다.
답은 며칠 후에 이 포스트에 추가로 올려놓도록 할 테니 여러분들도 한번 고민해 보고 어떤 것이 단일 책임의 원리를 위반하고 있다고 생각하는지 댓글을 남겨보면 좋겠다. 책에서는 SRP.는 단지 가이드라인일 뿐이지 꼭 이 방법을 따라야 한다는 것은 아니라고 설명하고 있다. 클래스의 기능과 프로젝트에 대한 상식, 그리고 경험을 통해서 디테일한 부분을 스스로 결정해야 한다고 설명하고 있으니 부담 없이 참여해 보시길…
원리 4)
리스코프 치환 원리 LSP(Liskov Substitution Principle)
자식 타입들은 부모 타입들이 사용되는 곳에 대체될 수 있어야 한다는 내용이다. 이는 잘 디자인된 상속에 관한 내용으로 부모 클래스를 상속할 때, 부모 클래스가 사용되는 곳은 아무 문제없이 자식 클래스도 사용할 수 있어야 한다는 것이다. 그렇지 않으면 상속을 잘못 사용하고 있다는 것.
예를 들어 Board라는 클래스는 대부분의 메소드에서 x와 y의 인자를 사용하지만 3DBoard 클래스의 경우는 x,y,z 인자를 사용한다. 이때 3DBoard 클래스가 Board 클래스를 상속하였을 때 3DBoard 클래스에서는 상속된 Board 클래스의 기능이 전혀 필요 없음에도 상속을 하는 경우이다.
이렇게 되었을 때는 상속을 통해서 얻는 것보다 잃는 것이 많아지는데 이는 불필요한 메소드와 구조상 가독성이 떨어지기 때문이다. 불필요한 상속을 피하고 LSP 따를 수 있는 방법으로는 아래와 같은 방법이 있을 수 있다고 설명한다.
1. 상속 보다는 연관을 사용한다
이것은 3DBoard에 Board 인스턴스를 가지고 있으며 Board를 사용하되 zpos 값을 통해서 3DBoard를 표현하는 방법이다.
2. 구성(Composition)을 사용하여 다른 클래스들의 행동을 조합한다.
이 방법은 하나의 인터페이스를 따르는 클래스들의 묶을 배열 형태로 저장하여 필요한 클래스를 동적으로 적용할 수 있는 방법이다. 구성의 경우 구성을 가지고 있는 클래스가 소멸했을 때는 그 클래스에 포함된 구성 요소들도 함께 소멸한다.
3. 집합(Aggregation)을 상용하여 구성에서 구성 요소들이 사라지지 않게 한다.
이 방법은 구성과 비슷하지만 구성 요소들이 외부에서도 사용할 수 있도록 하여 집합을 가지고 있는 인스턴스가 소멸했을 때에도 집합 요소들은 사라지지 않도록 하는 방법이다.
책에서는 LSP위한 방법으로 아래와 같이 정리하고 있다.
1. 위임(Delegation)
클래스의 행동을 변경하고 싶지 않고 그 행동을 스스로 구현하는 것이 그 클래스의 책임이 아닌 경우에는 그 행동을 다른 클래스에 위임(Delegation)한다.
2. 구성(Composition)
구성을 사용하여 하나 또는 여러 개의 클래스, 특히 비슷한 종류의 여러 클래스들로부터 행동을 재사용할 수 있다. 여러분의 객체가 다른 객체를 완전히 소유하고 있는 형태이며, 구성 관계로 연결된 객체는 여러분 객체의 외부에 독립적으로 존재할 수 없다.
3. 집합(Aggregation)
구성 관계의 이점을 바라지만 여러분 객체의 외부에서도 연결된 객체의 행동이 사용되는 경우, 집합을 사용한다.
덧붙여 책에서는 위임과 구성 그리고 집합을 상속보다 선호하면, 대개의 경우 소프트웨어는 더 유연하고, 유지보수성, 확장성, 그리고 재사용성이 좀더 좋아진다고 이야기 하고 있다. 꼭 그런 것은 아니겠지만 LSP를 따르지 않는 상속은 구조를 복잡하게 하고 재사용성이 떨어질 수 있기 때문이라고 할 수 있다. LSP를 따르는 상속의 경우에는 상속을 사용하는 것이 바람직할 것으로 생각된다.
글
우리나라 건설 문화?
Miscellaneous/Story
2007. 8. 27. 11:37
얼마 전부터 집 앞 건물에 살던 사람들이 이사 가는가 싶더니 어느 날 이틀 동안 그 큰 건물이 허물어졌다. 건물을 허물면서 날리는 먼지 때문에 이 더위에 창문도 못 열었었는데 건물 허무는데 이틀이 걸렸고 만 하루 동안 건물 잔해가 없어졌고 지금은 건물 기초 공사에 들어갔다.
비가 억수같이 쏟아지는 와중에도 골조 사이에 시멘트를 부어대고 있다. 상식적으로는 비가 올 때 시멘트 작업을 하게 되면 과다한 물기와 기포 때문에 기초공사가 부실해 질 수 있을 듯싶은데 작업 하시는 분들은 비가 와도 아랑곳 없이 작업에 열중이다.
이 속도라면 5층 이상 될 거 같은 건물은 한달 만에도 지어질 수 있을 듯싶다. 우리나라는 재건축에 대한 승인이 떨어지면 설계나 실질적인 공사 과정에서 모니터 하는 시스템이 갖춰져 있지 않은 것 같다. 있다고 한들 힘이 있겠냐만은…
앞 건물이 없어지면서 창문을 열면 시야가 시원했는데 빠른 속도로 건물이 다시금 올라오고 있어서 답답함이 밀려 온다… 내년에 이사를 가야겠다…
비가 억수같이 쏟아지는 와중에도 골조 사이에 시멘트를 부어대고 있다. 상식적으로는 비가 올 때 시멘트 작업을 하게 되면 과다한 물기와 기포 때문에 기초공사가 부실해 질 수 있을 듯싶은데 작업 하시는 분들은 비가 와도 아랑곳 없이 작업에 열중이다.
이 속도라면 5층 이상 될 거 같은 건물은 한달 만에도 지어질 수 있을 듯싶다. 우리나라는 재건축에 대한 승인이 떨어지면 설계나 실질적인 공사 과정에서 모니터 하는 시스템이 갖춰져 있지 않은 것 같다. 있다고 한들 힘이 있겠냐만은…
앞 건물이 없어지면서 창문을 열면 시야가 시원했는데 빠른 속도로 건물이 다시금 올라오고 있어서 답답함이 밀려 온다… 내년에 이사를 가야겠다…
글
[FlashPlayer] Adobe Flash Player v9.0.60.184 beta - H.264/HE-AAC지원
Miscellaneous/Etc
2007. 8. 27. 06:37
Adobe Systems는 지난 8월 21일 압축 규격 H.264와 HE-AAC (Hi Efficiency AAC)를 Flash Player에서 지원한다고 발표했다. 현재는 베타판 공개이고 이번 가을에 정식판을 발표할 예정이라고 한다.
베타판은 Flash Player 9 Update Downloads@Labs에서 다운로드 하여 인스톨 할 수 있는데 주의할 것은 기존에 있던 FlashPlayer를 언인스톨하고 설치 해야 한다. H.264가 FlashPlayer에 추가되면 iPod를 재생할 수 있다. H.264/HE-AAC 비디오 재생도 플래시플레이어에서 가능하게 되어 MPEG-4 표준을 따르고 있는 MP4, MOV, 3GP등을 재생할 수 있다고 한다.
현재는 단지 지원한다는 의미로 flv만큼의 퍼포먼스를 기대하기는 어려울 듯싶지만 지원한다는 자체의 의미는 매우 크다고 볼 수 있다. Adobe의 다이나믹 미디어 담당 Mark Randall에 의하면 최신판에서는 그래픽 카드의 하드웨어 가속을 이용할 수 있도록 설계되고 있어 듀얼 코어 프로세스에서 최적화 된다고 한다.
Microsoft는 Silverlight를 통해서 웹비디오계의 흐름에서 Flash의 독점에 도전할 의향인 듯 하다. Microsoft는 이미 MLB.com 등 대기업과 Silverlight 채용을 계약했다고 한다. Microsoft는 현시점에서 H.264의 지원을 이야기하고 있지 않지만 고객의 피드백에 근거해서 지원할 가능성이 있으면 지원할 방침이라고 전하고 있다.
웹비디오 기술의 흐름은 앞으로 웹의 발전 방향의 초석이 될 듯싶다. 메크로미디어가 어도비에 인수되었던 시점은 메크로미디어로서는 절호의 찬스였다는 생각이다. 하지만 어도비가 아니라 구글 쪽에서 메크로미디어를 인수 했다면 어떤 변화가 발생했을까 궁금하다. 간간히 구글이 flash만을 인수하거나 어도비를 인수할 수 있는 가능성에 대해서 조심스럽게 이야기를 하고 있는 듯하다. 어도비가 메크로미디어를 인수할 때 20%이상의 프리미엄이 있었던 것을 감안한다면 인수금이 대단할 것으로 예상된다. 만약 그렇게 된다면 엄청난 이슈가 될 것이지만 그러한 이야기는 구글 쪽에서 서비스 하고 있는 대부분이 FlashPlayer를 통해서 배포되고 있기 때문에 나오는 루머가 아닐까 싶다.
베타판은 Flash Player 9 Update Downloads@Labs에서 다운로드 하여 인스톨 할 수 있는데 주의할 것은 기존에 있던 FlashPlayer를 언인스톨하고 설치 해야 한다. H.264가 FlashPlayer에 추가되면 iPod를 재생할 수 있다. H.264/HE-AAC 비디오 재생도 플래시플레이어에서 가능하게 되어 MPEG-4 표준을 따르고 있는 MP4, MOV, 3GP등을 재생할 수 있다고 한다.
현재는 단지 지원한다는 의미로 flv만큼의 퍼포먼스를 기대하기는 어려울 듯싶지만 지원한다는 자체의 의미는 매우 크다고 볼 수 있다. Adobe의 다이나믹 미디어 담당 Mark Randall에 의하면 최신판에서는 그래픽 카드의 하드웨어 가속을 이용할 수 있도록 설계되고 있어 듀얼 코어 프로세스에서 최적화 된다고 한다.
Microsoft는 Silverlight를 통해서 웹비디오계의 흐름에서 Flash의 독점에 도전할 의향인 듯 하다. Microsoft는 이미 MLB.com 등 대기업과 Silverlight 채용을 계약했다고 한다. Microsoft는 현시점에서 H.264의 지원을 이야기하고 있지 않지만 고객의 피드백에 근거해서 지원할 가능성이 있으면 지원할 방침이라고 전하고 있다.
웹비디오 기술의 흐름은 앞으로 웹의 발전 방향의 초석이 될 듯싶다. 메크로미디어가 어도비에 인수되었던 시점은 메크로미디어로서는 절호의 찬스였다는 생각이다. 하지만 어도비가 아니라 구글 쪽에서 메크로미디어를 인수 했다면 어떤 변화가 발생했을까 궁금하다. 간간히 구글이 flash만을 인수하거나 어도비를 인수할 수 있는 가능성에 대해서 조심스럽게 이야기를 하고 있는 듯하다. 어도비가 메크로미디어를 인수할 때 20%이상의 프리미엄이 있었던 것을 감안한다면 인수금이 대단할 것으로 예상된다. 만약 그렇게 된다면 엄청난 이슈가 될 것이지만 그러한 이야기는 구글 쪽에서 서비스 하고 있는 대부분이 FlashPlayer를 통해서 배포되고 있기 때문에 나오는 루머가 아닐까 싶다.
