오버로딩과 오버라이딩은 이름이 비슷해 자주 헷갈리는 개념이다. 간단하게 말하면 오버로딩(Overloading)은 같은 이름의 메소드 여러개를 가지면서 매개변수의 유형과 개수가 달라도 되도록 하는 기술이고, 오버라이딩(Overriding)은 상위 클래스가 가지고 있는 메소드를 하위 클래스가 재정의해서 사용하는 것을 뜻한다. 오버로딩(Overloading) 우선 오버로딩(Overloading)은 같은 메소드라도 매개변수만 다르면 얼마든지 정의하고 사용할 수 있다. 하지만 너무 많은 오버로드 함수를 가지고 있는 것은 혼란을 야기할 수 있으므로 과도하게 사용하는 것은 좋지 않다. 오버로딩의 특징은 아래와 같다. 메소드 이름이 같아야 함 리턴형이 같아도 되고 달라도 됨 파라미터 개수가 달라야 함 파라미터 개수가 ..
주요 개념 Over-fetching Under-fetching REST-API GraphQL Over-fetching과 Under-fetching은 REST-API의 단점들 중 하나이다. 이 단점은 GraphQL을 사용해 극복할 수 있다. 간단하게 Over-fetching은 API를 호출 시 필요보다 많은 데이터(사용하지 않을)를 가져오는 것이다. 예를 들어 대기 오염 물질 중 미세먼지 데이터만 필요한데 온도, 습도, VOC, NO2 등의 다른 데이터까지 한 번에 받아오게 되는 경우가 있다. 그러므로 서버와 네트워크도 불필요한 자원이 추가되게 되고, 클라이언트도 필요없는 데이터를 수신해 자원을 낭비하게 될 수 있다. Under-fetching은 한 번의 통신으로 필요한 양의 데이터를 가져오지 못한다라는 ..
주요 개념 블랙박스 테스트(Black Box Testing) 화이트박스 테스트(White Box Testing) 소프트웨어 테스트 방식은 크게 두 가지로 나눌 수 있는데 바로 블랙박스 테스트(Black Box Testing)와 화이트박스 테스트(White Box Testing)이다. 블랙박스 테스트는 내부 구조/디자인/요소들 구현에 관한 내용들을 테스터에게 알리지 않고 테스트하는 방식이다. 화이트박스 테스트 또한 내부 구조/디자인/요소들 구현에 대한 테스트를 진행하지만 테스터에게 해당 내용들을 숙지시켜준 후 진행하는 테스트이다. 쉽게 말해 게임을 직접 플레이하며 게임상으로 드러난 결과물을 검사하는 것이 블랙박스 테스트이고, 게임 소프트웨어 내부의 프로그래밍 언어를 실행 단계에 맞게 추적하며 오류를 검사하..
OOM(Out Of Memory)이란 사용자에게 보이는 앱의 비정상 종료는 대부분 예외 발생에 따른 Crash가 그 원인이지만, 기타 주요 원인으로는 Out Of Memory(OOM)를 들 수 있다. 애플리케이션이 대량의 메모리를 이용하여 시스템 메모리가 부족해지면, OS에 따라 해당 앱은 강제로 종료된다. 일반적으로 사용자에게 보이지 않는(백그라운드 또는 작동하지 않는) 앱이 우선 종료되지만, 앱이 표시되고 있는 상태에서도 대량의 메모리를 소모하여 시스템 메모리가 부족해지면 OS에 의해 강제로 종료된다. OOM에 의해 앱이 종료되는 경우, 앱 프로세스 내부에서 이벤트를 취득할 수 없으며, 앱 프로세스 외부에서 강제로 종료되기 때문에 정확하게 OOM을 검출할 수 없다. 또한, 앱이 표시된 상태에서 프로세..
BLoC(Business Logic Component) BLoC(Business Logic Component)란 UI와 Business Logic을 분리하여 만드는 방식을 의미한다. BLoC는 Flutter의 state를 관리하는 디자인 패턴 중 하나이며 Google 개발자에 의해 고안되었다. Flutter는 state에 따라 렌더링이 일어나기 때문에, 상태 관리가 매우 중요하다. 또한 상태 관리는 Flutter에서 만의 문제가 아닌 모든 개발에서 중요하게 고려되어야 할 사항이다. 그러므로 이 BLoC Pattern은 Flutter를 위해 설계되었지만 다른 프레임워크나 언어에서도 적용 가능한 디자인 패턴이다. 예를 들어 React Native에서 setState라는 Hook을 이용해 상태를 갱신시키며 r..
컴퓨터 프로그래밍에서 SOLID란 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙이다. 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다. SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때까지 소프트웨어 소스 코드를 리팩터링하여 스파게티 코드, 에일리언 코드 또는 레거시코드가 되지 않도록 하기 위한 지침이다. 이렇게 설계된 소프트웨어는 재사용이 많아지고, 수정이 최소화되기 때문에 결국 유지 보수가 용이해진다. 물론 처음에 SOILD 원칙에 따라 소스코드를 작성하였어도 지속적으로 추가, 수정 등을 진행하며 리팩터링을 수행하여야 한다. SOILD는 아래 5가지의 원칙의 첫 글자를 따서 명명되었다...
