ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 2024.3.28
    TIL 2024. 3. 28. 21:03

    우수 답변

     

    8. 박싱과 언박싱에 대하여 설명해주세요.

    8 - 1. 박싱, 언박싱을 사용할 때 주의해야 할 점이 있다면 무엇이 있나요?

     

    ★메모리 오버헤드, 타입 안정성

    박싱 / 언박싱은 단순한 정의를 묻는 질문이 아닙니다. 보통 이로인한 메모리 오버헤드를 이해하고 있는지, 타입 안정성에 대한 고민을 할 수 있는지를 볼수 있는 질문입니다. 방싱 언박싱의 문제를 제시하고 이를 위한 해결 방법(제네릭) 을 설명하며 본인이 프로젝트에 녹여낸 경험을 같이 이야기 하면 좋습니다

     

    박싱은 값 형식을 참조 형식으로 변환해주는 것입니다. 언박싱은 박싱했던 값을 다시 값 타입으로 변환시켜주는것입니다.
    박싱 언박싱 사용 시
    주의점 박싱을 사용할 때 주의점은 박싱이 힙메모리에 객체를 생성하기 때문에 그래서 박싱을 자주 사용하면 가비지 컬렉터가 사용되서 메모리에 부담이 커질수 있고 언박싱은 데이터를 풀때 데이터와 잘못된 타입으로 언박싱을 시도하면 예외처리가 발생하면서 변환이 안되않아 데이터와 변환타입을 잘 비교하고 변환해야합니다.

     

    박싱은 값 형식을 참조 형식으로 변환해주는 것이고 언박싱은 박싱했던 값을 값 형식으로 변환시켜주는 것입니다.
    박싱을 하면 값이 참조 형식으로 변환되어 힙 메모리에 객체를 생성하기 때문에 박싱을 자주 사용하면 힙 메모리에 데이터가 많아지면서 가비지 컬렉터가 정리하는 메모리 또한 증가하게 되기 때문에 주의해야합니다.
    언박싱을 할 때에는 박싱한 값의 원래 타입으로 변환하는 것이 아니라면 변환이 되지 않아 오류가 발생하므로 주의해야합니다.


     

    9. 배열과 List, ArrayList, Dictionary 의 차이점을 설명해주세요.

    9 - 1. Dictionary는 어떻게 구현해야 하나요?

    9 - 2. Dictionary 검색이 빠른 이유는 무엇인가요?

     

    ★필요한 상황

    자료구조는 단순한 설명보다 그로인한 특성을 파악하는 것이 중요합니다. 각자의 장단점을 알필요가 없었다면 컬렉션은 배열 하나밖에 없었을겁니다. 하지만 상황에 맞게 더 효율적인 방법들을 고민하여 나온 것들이니 어떤 상황에 사용되는것이 좋은지 고민해보세요.

     

    배열 - 연속된 메모리 공간으로 이루어져 메모리 관리가 용이하며 순서대로 되어있기에 그에 맞춰 index로 이루어져 접근을 빠르게 할 수 있다. 하지만 동적 할당이 불가하여 크기가 정적이다.
    (단점 - 할당된 메모리 블록은 사용하지 않아도 고정되어 있어 메모리 낭비가 발생 가능)
    (사용처 - 변경 가능성이 없는 고정된 수의 요소가 있고 비순차적인 방식으로 자주 엑세스를 해야할 때 편리)
    리스트 - 리스트는 C#에서 제너릭 형식의 List로 제공되어 크기가 동적이다. 순차적으로 요소를 추가하고 제거하는 데에 편리하고 제너릭 형식이기에 박싱 언박싱이 일어나지 않아 이점이 있지만, 리스트는 다음 데이터의 주소값을 가지고 있어야 하여 메모리를 많이 쓰게되고 특별한 키값이 존재하지 않아 검색에 유용하지 않다.
    (단점 - 내부적으로는 배열의 형태이기 때문에 동적으로 추가할 때에 성능의 저하가 발생할 수 있다. 그리고 커다란 리스트를 만들 경우 순차적으로 검색하기 때문에 굉장히 비효율적)
    (사용처 - 요소를 자주 추가하고 제거할 때에 편리, 다음 주소지를 알고 있어 반복문을 사용하기에 적합)
    배열 리스트 - 제너릭이 사용되기 전 자료구조로 object를 인자로 갖기에 어떤 타입 객체든 저장할 수 있지만, 박싱 언박싱이 일어나 성능이 떨어질 수 있다. 그렇기에 이후에는 리스트를 사용하는 것이 권장되고 있다.
    딕셔너리 - HashTable을 기반으로 Key와 Value로 데이터를 세트로 저장하며 키값을 통해 검색할 수 있는 자료구조이다.마찬가지로 동적으로 크기가 조절 되며 제네릭 클래스이기에 자료형의 제한이 없습니다. 키 값을 통해 특정한 데이터를 탐색하는 데에 특화되어 있습니다.
    (단점 - 연속구조가 아니기에 반복문 사용이 적합하지 않고 기반인 Hashtable과 달리 여러 타입을 수용할 수 없다.)
    (사용처 - 특정한 값을 검색하고 탐색하는 자료구조에 적합하다. 예시로 퀘스트 자료구조를 만든다면 해당 퀘스트의 ID값으로 찾는 것이 가능하다.)
    (꼬리질문) Dictionary는 어떻게 구현해야 하나요?
    Dictionary 클래스는 <Key, Value> 로 되어있어 키와 데이터의 유형을 지정해주어 선언해야 합니다.'Add'와 'Remove' 메서드를 통해 추가 및 제거하고 키의 유무를 확인하는 'ContainsKey' 메서드도 존재합니다.
    (꼬리질문) Dictionary 검색이 빠른 이유는 무엇인가요?
    HashTable 기반으로 키를 고유한 인덱스로 변환하여 저장하여 이 값이 저장되는 데이터의 배열의 인덱스로 사용되어 키를 통해 위치를 찾기 때문에 데이터의 크기에 관계없이 일정한 시간 내에 데이터를 찾을 수 있습니다. 그렇기에 시간 복잡도도 O(1)로 되어 있습니다.

     

    배열은 연속된 메모리 공간으로 이루어져 있어 순서에 맞춰 index로 이루어져 있어 접근을 빠르게 할 수 있으며, 메모리 관리에 용의합니다. 동적 할당이 불가하기 때문에 크기가 고정되어 있어서 사용하지 않는 메모리가 있을 수 있습니다. 따라서 메모리 크기의 변경이 필요없으며, 비순차적인 방식으로 자주 사용할 때 편리합니다.
    리스트는 크기가 동적이고 순차적으로 요소를 추가하고 제거가 가능합니다. 제너릭 형식을 제공받기 때문에 박싱과 언박싱이 일어나지 않는 이점이 있기만 연속된 구조이지만 배열과 다르게 연속된 메모리 공간으로 이루어진 것이 아니므로 다음 데이터의 주소값을 가지고 있어야합니다. 또한 순차적으로 검색하기 때문에 비효율적이기도 합니다. 그러나 요소를 자주 추가하고 제거할 때 편리하고 다음 데이터의 주소값을 가지고 있어 반복문에서 사용하기 좋습니다.
    배열 리스트는 다양한 타입의 객체를 저장할 수 있지만 리스트와 다르게 박싱과 언박싱을 이용하기 때문에 성능이 떨어지므로 리스트 사용이 권장되고 있습니다.
    딕셔너리는 <Key, Value> 형태로 Key와 Value 데이터를 세트로 저장하여 Key 값을 통해 검색할 수 있습니다. 연속된 구조가 아니므로 반복문에서 사용하기에는 적합하지 않으며 특정 값을 검색하고 탐색하는 것에 적합합니다. 리스트와 마찬가지로 크기가 동적이며 Add와 Remove를 이용해서 요소를 추가하거나 제거하는 것이 편리합니다. Key가 같을 경우 중복되서 저장이 되지 않으므로 ContainsKey를 통해서 사용할 Key값이 있는지 확인이 가능합니다. 그러므로 Key값이 고유하기 때문에 데이터의 크기에 상관없이 일정시간 내에 데이터를 바로 찾을 수 있어 시간 복잡도가 O(1)입니다. 

     

    10. 제네릭이란 무엇인가요?

     

    제네릭은 타입 안정성을 강화하고 재활용성을 높일수 있는 유용한 기능입니다. 핵심은 런타임에 결정되도록 타입을 설정할 수 있다는 것이며, List 등에서 제네릭을 쓰지 않았을때와 제네릭을 썻을때 어떤 이점이 있는지 설명할수있으면 좋습니다. 이 방법을 잘 이해해두면 면접을 떠나 프로그래밍 스킬이 많이 향상되니 꾸준히 공부해보세요.

     

    제네릭은 데이터 형식에 관계없이 재사용 가능한 코드를 작성할 수 있도록 하는 프로그래밍 개념입니다. 제네릭을 사용하면 클래스나 메서드를 정의할 때 데이터 형식을 지정하지 않고, 실행 시점에 실제 데이터 형식을 지정할 수 있습니다. 이를 통해 코드의 재사용성과 유연성을 높일 수 있습니다. 예를 들어, 제네릭을 사용하여 리스트나 딕셔너리 같은 컬렉션 클래스를 만들면, 다양한 데이터 형식을 저장할 수 있습니다.

     

    'TIL' 카테고리의 다른 글

    2024.4.17  (0) 2024.04.17
    2024.4.1  (1) 2024.04.01
    2024.3.27  (1) 2024.03.27
    2024.3.26  (0) 2024.03.26
    2024.3.15  (0) 2024.03.15
Designed by Tistory.