Q: Association, Aggregation, Composition 이 세가지의 차이가 무엇인가요? 구현 시 어떻게 적용되는지 설명 해주세요. (질문자: ???)



A: 
Association: 모든 오브젝트가 각자의 라이프사이클을 가지고 있고, 어떤 오브젝트가 다른 오브젝트를 소유하지는 않은 경우입니다.

예를 들면, 선생님과 학생의 경우를 들 수 있습니다. 많은 학생이 한 선생님에게 Association를 가질 수 있고, 한 학생이 여러 선생님에게 Association를 가질 수도 있습니다. 하지만 이 관계에는 누가 누구를 소유하거나 하지는 않습니다. 각자가 생성/소멸을 독립적으로 합니다.


Aggregation: Association의 특별한 경우인데, 모든 오브젝트가 각자의 라이프사이클을 가지고 있으며, 한 오브젝트가 다른 오브젝트를 소유하고 있는 경우입니다.

선생님이 어떤 부서에 Aggregation되어 있다고 합시다. 소속된 관계이기 때문에, 한 선생님이 여러 부서에 Aggregation될 수는 없습니다. 그렇다고 해서 부서가 소멸될 때 선생님도 소멸되는 것은 아닙니다. 이것을 "has-a" 관계라고 할 수 있습니다.


Composition: Aggregation의 특별한 경우인데, 이것을 "죽음의" 연관관계라고 부를 수도 있습니다. 강력하게 연관된 Aggregation이며, 자식 오브젝트는 자신의 라이프사이클을 가지지 않고, 부모 오브젝트가 소멸될 경우 자식 오브젝트도 함께 소멸됩니다.

이 관계는 집과 그 안의 방 사이의 관계라 할 수 있습니다. 집은 여러 개의 방을 가지고 있고, 방은 절대로 독립적인 라이프사이클을 가질 수 없습니다. 우리가 집을 소멸시키면, 방도 함께 소멸될 것입니다.

또 다른 예로, 문제와 선택지의 관계를 들 수 있습니다. 한 문제는 여러 개의 선택지를 가질 수 있고, 선택지는 여러 문제에 속할 수 없습니다. 문제를 소멸시킬 때, 선택지도 함께 소멸될 것입니다. (역주: 이 예는 틀릴 수도 있습니다. 여러 선택지와 여러 문제가 함께 있을수도 있으니까요!)



(답변자:Varun Gupta)

_


_

What is the difference between association, aggregation and composition? Please explain in terms of implementation.

shareeditflag
_


  • Association is a relationship where all objects have their own lifecycle and there is no owner.

    Let’s take an example of Teacher and Student. Multiple students can associate with single teacher and single student can associate with multiple teachers, but there is no ownership between the objects and both have their own lifecycle. Both can be created and deleted independently.

  • Aggregation is a specialised form of Association where all objects have their own lifecycle, but there is ownership and child objects can not belong to another parent object.

    Let’s take an example of Department and teacher. A single teacher can not belong to multiple departments, but if we delete the department, the teacher object will not be destroyed. We can think about it as a “has-a” relationship.

  • Composition is again specialised form of Aggregation and we can call this as a “death” relationship. It is a strong type of Aggregation. Child object does not have its lifecycle and if parent object is deleted, all child objects will also be deleted.

    Let’s take again an example of relationship between House and Rooms. House can contain multiple rooms - there is no independent life of room and any room can not belong to two different houses. If we delete the house - room will automatically be deleted.

    Let’s take another example relationship between Questions and Options. Single questions can have multiple options and option can not belong to multiple questions. If we delete the questions, options will automatically be deleted.

shareeditflag


신고
Posted by StanleyKou





안드로이드, iOS앱을 따로따로 만드는 것은 귀찮은 일입니다.

특히, 성능과 밀접하지 않은, 서버에서 데이터를 읽어 와서 화면에 리스트 형태로 출력하는게 앱이 하는 일의 전부라면

하나의 소스로 안드로이드, iOS앱을 동시에 만들어주는 Cross-platform 개발에 눈길이 갈 법한 일이죠.

한 때는 PhoneGap, Sencha touch 등이 모바일의 미래인 것처럼 수많은 강좌가 생기고, 엄청난 마케팅이 이어졌습니다.

물론 이들은 목적한 만큼의 성과를 거두었고, 결과물도 그럭저럭 괜찮았습니다.

하지만 이게 전부일까요? 그럭저럭 괜찮은 결과물에 만족하지 못하는 사람들도 많았고, 분명 더 발전의 여지가 있을 것이라고 모두들 예상했었죠.

그렇다면, 2016년 7월 시점에서 인기있는 Cross-platform 개발환경은 어떤 것이 있는지 구글트렌트에 물어보겠습니다.

참고:

http://techbeacon.com/10-cross-platform-mobile-development-tools-enterprises

http://thinkapps.com/blog/development/develop-for-ios-v-android-cross-platform-tools/






하위권은 모두 제외하고, 상위 5개의 크로스플랫폼 환경만 출력했습니다.

주목할 만한점은, 대부분의 크로스플랫폼 개발환경이 하락세인데 비해 Xamarin이 폭발적인 증가세를 보이고 있다는 점입니다.

그리고 꽤 오랫동안 시장의 문의 두드려왔던 NativeScript도 상승세를 보이고 있네요.

Xamarin과 NativeScript가 증가세를 보이는 이유는, 바로 앱의 실행 속도 때문입니다. 기존의 PhoneGap등의 환경은 마치 웹페이지를 띄우는 것 처럼, 약간의 버벅거림이 있었지만 Xamarin, NativeScript는 Native로 빌드를 해버리기 때문에 속도 면에서 Native앱과 거의 동일합니다.

물론 아직은 Native 개발환경을 무시할 수는 없습니다. 모바일 개발진영은 자신들만의 라이브러리를 굉장히 많이 쌓아왔고, 이들 라이브러리가 크로스플랫폼으로 쉽게 이식될 수 있는지는 장담할 수 없습니다.

특히 구글은 자체적으로 IntelliJ를 기반으로한 Android Studio를 출시했는데, 메모리 분석 및 성능측정 기능, 개발 편의성 향상 등 무시무시한 기능을 갖추고 있으며, Xcode역시 지속적으로 버전업 되고 있습니다.

과연 모바일 개발환경의 미래는 어떻게 될까요?

한 가지 분명한 것은, Xamarin을 더 이상 무시하기 어렵다는 것입니다. Android 개발을 위해 Java를, iOS 개발을 위해 Objective-C를 배웠다면, 이제 다시 Xamarin을 위해  C#을 배울 때가 온 걸까요?


Xamarin

https://www.xamarin.com


Native Script

https://www.nativescript.org




신고
Posted by StanleyKou





구글 IO 2016에서 안드로이드 스튜디오 업데이트가 발표되었습니다.




이제는 이클립스를 떠나 안드로이드 스튜디오로 갈 때가 된 것 같네요. 이미 상위 120여개 앱 중 95%가 안드로이드 스튜디오로 만들어지고 있다고하니, 안드로이드 스튜디오가 대세인 것 같습니다.


이번 세미나에서 언급된 주요 특징은 아래와 같습니다.

- APK Analyzer를 이용한 분석 및 디컴파일 기능 (앱의 용량이 불필요하게 크지는 않은지, 이미지 리소스 확인, dex 파일 내용 보기 등)

- C++ 디버깅 기능 (JNI를 이용하여 만든 라이브러리 내부까지 함께 디버깅. 이클립스에서 이걸 하려면 GDB 설정 등등... 꽤 번거로운 작업을 해주어야 했습니다)

- 프로젝트에서 이용하고 있는 라이브러리 최신 버전으로 업데이트 기능 (Repository에서 최신버전이 있는지 자동으로 검색해 주고 클릭 한번에 교체 가능)

- 현재 프로젝트가 git에 연동되어있다면, 최신 버전을 다운로드 받아 빌드하는 기능

- 메뉴, Preference 등을 드래그 앤 드롭으로 제작할 수 있는 UI 편집 툴 (이클립스의 xml 편집 툴은...... MFC 같은 고전 툴에 비해서도 못써먹을 물건이었습니다)

- Constraint layout 추가. 이 레이아웃은 다른 뷰와 위치가 연동되어 있어 드래그 앤 드롭 시 위치가 연동되어 변경 됨.

- FireBase기능을 이용하여 크래시 리포트 등을 편리하게 할 수 있음.

- 코드 인스펙션 기능이 강화되어, 좋지않은 안드로이드 코드에 대해 경고 문구를 띄워줌

- 쓰지 않는 스트링 리소스를 지우고 싶을 때, 안드로이드 스튜디오가 해당 리소스가 정말 쓰지 않는 리소스인지 확인해 주는 기능

- UI 동작을 했을 때, 어떤 id를 가진 요소를 클릭했는지 등의 정보를 표시해 주는 기능

- 레이아웃 에디터 대폭 강화로, XML을 직접 수정해야 하는 경우를 대폭 줄임.

- Instant Run 기능으로, 앱을 새로 빌드하지 않고도 코드를 수정한 결과를 즉시(!) 앱에 적용

- Java 8 지원, 람다 표현식 지원, Annotation 프로세스 지원

- 에뮬레이터가 최대 10배까지 빨라짐 (이클립스에서 실행시키는 안드로이드 에뮬레이터는 못써먹을 물건이었습니다)

- 에스프레서 테스트 기록 기능

신고
Posted by StanleyKou







티스토리 툴바