HERSTORY

[후기] 2021 상반기 네이버 신입 공채 최종 합격 후기와 준비 과정

Tue, 28 Sep 2021 00:00:00 +0000

입사한 지가 엊그제같은데 벌써 하반기 공채를 한다길래 기억을 되살려 적어본다..🙄

일정

서류 마감	코딩테스트	서류+코테 발표	1차 면접	1차 면접 발표	2차 면접	최종 발표	입사
4/12	4/24	5/14 5시	6/2 ~ 6/15	6/24 4시	7/5 ~ 7/8	7/15 6시 45분	7/28

네이버는 각 전형이 정말 오래 걸렸다. 각 전형의 합격 발표는 2주 정도로 나쁘지 않다고 생각하는데, 전형 사이 간격이 한 달 간격으로 너무 길어서 기다리기 힘들었다 ㅠㅠ

서류

네이버는 다른 기업들과 다르게 서류 합격이 따로 없고 코딩테스트를 본 후 서류와 코딩테스트를 종합해 면접 대상자를 정한다. 서류에 큰 신경을 쓰지 않아도 되고, 뛰어난 스펙이나 자소설은 필요 없다고 생각한다.

👉 스펙

정량적인 스펙은 각 전형에 참고는 되겠지만 합불합에 영향은 없는 것 같다. 나는 학점 3.82/4.5, 인턴 1회, 정보처리기사, 토익 895, 오픽 IM2 이 있어서 적었지만 면접에서 아무도 안 궁금해하셨다..

👉 문항

1️⃣ 다음 중 자신 있는 분야를 우선순위 별로 작성해 주세요. ■ FE 개발 ■ iOS 개발 ■ Android 개발 ■ BE 개발

2️⃣ 가장 자신 있는 또는 좋아하는 컴퓨터공학 관련 이수 과목명과 성적, 그리고 해당 과목을 택한 이유를 각각 기재해 주세요.

3️⃣ 기술적으로 어려운 문제를 해결한 경험을 상세히 작성해 주세요. (학교수업/프로젝트/경진대회/대외활동 등) 맞닥뜨렸던 문제를 '구체적'으로 기술하고, 본인의 접근 방법과 해결 과정, 그리고 실제 결과를 '상세히' 기술해 주세요. 문제를 잘 해결하셨다면 그 경험에서 아쉬운 점 혹은 더 나은 방법은 없었을지에 대한 고민 과정을 함께 작성해 주세요. 해결하지 못한 경험이더라도 해결을 위해 얼마나 깊이 있게 고민을 했는지 그 과정에 대해 이야기해 주세요.
* 코드로 설명해 주셔도 좋습니다.

사실상 자소서 문항은 1개나 다름 없다. 1, 2번은 그냥 적으면 된다. 다만 2번 문항은 A+ 받은 과목만 6개 나열할 필요는 없고, B+이나 C+를 받더라도 정말 자신 있는 전공 과목을 적으면 될 것 같다. 2번 문항이 1차 면접때 반영이 되는 느낌이다. 면접때 어떤 문제가 나와도 술술 말할 수 있는 과목으로 적도록 하자. 나는 정말 자신있고 재밌었던 과목들로 A+ 과목 4개, B+ 과목 2개를 적었다.

3번 문항도 그냥 적으면 된다. 나는 코드도 포함시켰는데, 면접 스터디할 때 보니 코드를 포함시키지 않은 사람이 더 많다. 전체적인 내용은 발생한 문제, 해결하기 위해 시도한 방법들, 최종적으로 선택한 방법과 그 이유, 해결하면서 느낀점 등으로 적었고 마크다운 문법을 사용해 적었다. 코드를 어떻게 포함시켜야 하는지 모르겠어서 그냥 개발자들에게 익숙한 마크다운으로 적었는데, 지원서에는 텍스트로만 올라가서 가독성이 더 떨어진다ㅠㅠ 그래도 날 뽑아준 걸 보면 형식에는 신경을 쓰는 것 같진 않고 내용만 보는 것 같다.

👉 포트폴리오

포트폴리오는 선택이었던 것 같은데, 웬만하면 넣는 것을 추천한다. 문항이 적기 때문에 코딩테스트 결과가 애매하면 포트폴리오로 판단할 것 같다는 생각때문이다. 나도 코딩테스트 결과는 애매했는데 포트폴리오때문에 붙은 것 같다.. 노션으로 포트폴리오를 작성했고, 면접에서 내 포폴을 보시고 포폴이 세련됐다고 칭찬도 들었다.🤗 내용만 잘 간추린다면 ppt로 해도 상관은 없어 보인다.
내 포트폴리오는 여기서 볼 수 있다.

코딩테스트

네이버는 네카라 중에 코딩테스트가 비교적 쉬운 편이다. 내가 경험한 라인, 삼성, 네이버의 코테를 비교해보자면
(카카오>>>>>>)라인>>>네이버>>삼성 이다.

코딩테스트 준비

1월 말부터 코딩테스트가 있던 4월 말까지 약 3개월을 공부했다. 첫 달은 인프런 강의를 들으면서 기본 개념을 공부했고, 나머지 두달동안은 매일 알고리즘 문제를 풀었다. C++ 언어를 선택했고 알고리즘을 어떻게 시작할 지 고민된다면 인프런의 it 취업을 위한 알고리즘 문제풀이 (with C/C++) : 코딩테스트 대비 강의를 정말 추천한다. 한 달 정도면 강의를 다 들을 수 있고 강의를 다 들은 후에도 개념을 복습하기 좋다.

강의를 다 듣고 나서부터는 백준, 프로그래머스의 알고리즘 문제를 매일 1~4문제씩, 코딩테스트 직전에는 이전에 푼 문제들을 복습하면서 6~8문제씩 풀었다. 막학기라 3학점짜리 수업 하나만 듣는 상태였고 첫 취준이라 정말 가고싶은 기업만 소신 지원해서 시간이 넉넉했기 때문에 세 달 동안은 정말 알고리즘에만 집중했다.

코딩테스트

네이버의 코딩테스트는 캠을 켠 상태로 프로그래머스에서 비대면으로 진행됐고 IDE는 쓸 수 없었다. 코딩테스트 직전에 IDE를 쓰지 말고 프로그래머스에서 많이 연습하는 것을 추천한다. 팁은 프로그래머스에서도 print 함수는 되니까 오류가 생긴다면 라이브러리를 추가해서 print로 디버깅을 하고 제출할 때에는 삭제하면 된다.

이번 코테는 2시간동안 4문제를 풀어야했다.
1번은 단순 구현으로 언어만 쓸 줄 안다면 누구나 풀 수 있는 문제였다. 백준 기준 브론즈 ~ 실버정도로 예상한다.
2번은 문자열 구현이었던 것 같은데, 조건이 여러개라 C++로 풀기엔 살짝 까다로웠던 것으로 기억한다. 실버1 ~ 골드5 정도일 것 같다.
3번은 풀다가 시간이 초과돼서 다 못 풀었지만 푼 사람들의 말을 들어보면 슬라이딩 윈도우?로 푸는 효율성 문제였다.
4번은 삼성 역량테스트 기출과 비슷하지만 난이도는 훨씬 높았고 골드 1정도 되는 것 같다.

나는 (테케 기준) 1,2,4번 총 3문제를 풀었다. 3번의 효율성 문제는 자신이 없었고 4번이 삼성 코테때문에 연습했던 유형이라 4번에 집중했는데, 코딩테스트가 끝나고 복기해봤을 때 딱 테스트케이스들만 돌아가는 로직으로 짜서 실수를 한 걸 깨닫고 머리를 쥐어뜯었다 😭.. 하지만 붙여준 걸로 봐서는 코드의 가독성이나 히든 테케가 다 맞는지 보다는 주어진 테케라도 맞게 돌아가는지 + 서류를 종합해서 면접 대상자를 정하는 것 같다.

➕) 라인, 네이버 코딩테스트 기출

내 기억이 맞다면 프로그래머스 위클리 챌린지에 올라온 문제가 라인, 네이버 코딩테스트 기출문제와 유사하다.

2주차 상호평가와 3주차 퍼즐조각 채우기가 각각 네이버의 1번, 4번이었고
4주차 직업군 추천하기와 7주차 입실 퇴실이 라인 문제였던걸로 기억한다.

시간이 된다면 한 번씩 풀고 가는 것을 추천한다.

합격

👿 이 정도면 솔직히 붙여줘야지💦
😭 아니 그래도 네이번데.. 나같은 쩌리를 붙여줄까..? 제발 붙여주세요 잘할게요ㅠㅠ
가 공존하는 3주가 지난 뒤 합격 통보를 받았다.

1차 면접

면접은 총 두달 반정도 준비했다. 지원서를 작성하면서 틈틈이 자아성찰을 했고, 코딩테스트가 끝난 후부터는 발표가 나지 않았더라도 면접에만 올인했다. 면접 준비는 한달 ~ 한달 반정도면 충분할 것 같은데, 전형이 너무 오래 걸려서 의도치않게 길게 준비했다. 그래도 계속 복습할 수 있어서 자기계발 시간은 된다..😂
지칠 때는 유투브 쩜튜브님의 네이버 합격 후기를 보면서 행복회로를 돌리며 마음을 다잡았다.

면접 준비

👉 면접 스터디

동아리 면접 말고는 면접 경험이 없던 상황이라 면접 스터디를 총 8번 했다. 7번은 삼성, 1번은 네이버 2차 면접을 위해 진행했는데 결론적으로 면접 스터디는 강력 추천이다:bangbang: 혼자 취준을 하면서 늘어지던 시기에 다른 사람들을 보며 좋은 자극을 받을 수 있었다.

스터디에서는 주로 모의 면접을 진행하면서 인성 면접 질문, 직무 면접 질문을 서로 물어봐주고 대답하면서 피드백을 해주는 형태였다. 면접 스터디를 한다고 해서 실제 면접때 떨지 않은 건 아니었지만 미리 경험을 하고 대비할 수 있어서 좋았다.

👉 CS 공부 방법

스터디 이외 시간에는 전공과목을 바탕으로 자료구조, 알고리즘, 네트워크, 운영체제, 컴퓨터구조, 데이터베이스를 복습했고 추가로 내가 프로젝트에서 사용했던 언어와 기술들을 TIL에 적으며 공부했다.

운영체제와 컴퓨터네트워크는 인터넷에 돌아다니는 무료 강의를 들었는데, 정말 정말 도움이 되었다. 이화여대 운영체제 강의는 설명도 잘 하시는데다가 학부때로 돌아가서 다시 공부하는 기분이라 재밌었고, 유투브 네트워크 강의는 학부때 네포자였는데 그때 이해 못했던 개념들을 쉽고 재밌게 이해할 수 있어서 좋았다. 강의는 알고리즘 공부와 병행하면서 천천히 들었다.

나머지 과목들은 여러 깃허브를 참고하면서 공부 방향을 잡았고, 토픽별로 정리하며 내가 이해한 내용을 남에게 설명해줄 수 있을 만큼 말로 뱉는 연습을 했다. 반 이해, 반 암기였다.

👉 면접 질문 리스트

인성 질문과 CS 질문 리스트는 내가 깃허브에 정리해놓은 💚 tech_interview.zip 💚 레포지토리를 참고하면 도움이 될 것이다.

면접

면접 전에 면접 키트¹를 택배로 배송해주고, Zoom을 통해 1:3으로 1시간 30분동안 진행했다. 면접관으로는 팀 리더급 분들이 들어오신다. 1시간 30분이라길래 시간이 남을 줄 알았는데 꽉 채워서 풀로 1시간 30분동안 면접을 봤다. (면접 보다보면 시간이 사라진다…)

네이버 면접은 정말 정해진 방식이 없다. 그나마 1차 면접은 문제 은행식으로, 수리(고딩때 배운 확률과 통계 느낌), 손코딩, CS, 기타 개발 지식과 자소서에 기반한 질문을 주신다.
여기서 어떤 문제가 나올 지, 몇 개씩 나올지는 사람마다 다르다._{진리의 면바면}

손코딩만 하다 끝나는 사람도 있고, CS만 물어보는 경우도 있고, 수리 문제를 많이 물어보는 경우도 있다. 나는 창의수리 1문제, 손코딩 0개가 나왔고 CS + 자소서 관련 개발 지식이 자잘한 것 포함 40~50개였다.

1차 면접의 팁은 지원서 2번 문항(자신있는 전공과목)을 자신에게 유리하게 적는 것이다. 지원서를 참고해서 문제를 제출해주시는 것 같다. 모르는 문제가 나오는 경우에는 그냥 모른다고 대답하자. 그리고 면접때는 꼭 내가 공부 안 한 것만 물어보니 평소에 공부를 열심히 하자..😓

면접 키트 : 스마트펜, 스마트보드, 네이버 서비스 이용권(쿠키, 바이브 등)

합격

2차 면접

1차 면접이 끝나고 할 게 없어서(공부를 하고 싶지 않아서🤥) 알고리즘만 간간이 몇 개 풀다가 합격 소식을 받고 다시 면접 준비에 돌입했다.

면접 준비

사실 2차 때에는 정말 준비하기 싫었다. 후기를 봐도 큰 정보가 없고 긴 면접 준비 기간때문에 지치기도 해서 쉬엄쉬엄 준비를 했다.
1차 면접 때 못 푼 문제 해답 찾기, 면접 스터디 1회, 자소서 다시 보기, 면접 질문 다시보기, 자아성찰을 주로 했다.

면접

2차 면접은 1:2로 40분정도 진행되었다. 면접관으로는 조직장(책임 리더)급의 분들이 오신다. 2차는 1차때보다 더 정해진 형식이 없어서 정말 말할 게 없다. 여러 후기에서 왜 그렇게 2차 면접 정보가 적었는지 면접을 보고 나서 알게 되었다. 인성 질문만 100%인 사람, 기술 질문만 100%인 사람 등 사람마다 다르다.

나는 기술 질문만 100%였다. 전체적인 분위기는 시니어 개발자와 개발 얘기로 티타임을 갖는 느낌이다. ㅇㅇ에 대해 설명해달라고 질문을 끊임없이 던져주시지만 면접보다는 개발 주제로 얘기를 나누는 느낌이었고 결론은 정말 좋은 경험이었다. 면접관분들이 내가 🐶소리를 해도 끝까지 들어주시고 정말 친절하셨다.🥲

2차까지 온 사람들은 자신의 개발 열정만 어필한다면 어렵지 않게 붙을 것 같다.

최종 합격

2차 면접 초반 분위기는 좋았는데 마지막 10분을 말아먹어서 합격할 것 같으면서도 떨어질까봐 불안했고, 삼성 때 무조건 붙을 줄 알고 혼자 설레발 쳤다가 떨어졌던 기억때문에 마음을 비우고있었는데 꽤 빠르게 일주일만에 합격 통보가 났다. 면접이 정말 좋았어서 떨어지더라도 하반기에 다시 지원할 생각이었는데 이렇게 덜컥 붙어버리니 너무 좋았다.

벌써 입사 두달 차가 됐고 아직 말하는 🥔 이지만.. 복지도 짱짱하고 대우도 짱짱해서 아주 만족하면서 다니고 있다.

이 글을 보게 된 네이버 지원자들은 모두 합격하셔서 동료로 뵙길 바라겠습니다! 화이팅 💪

[Design Pattern] GoF 생성 패턴 - 상태 패턴(State Pattern)

Mon, 12 Jul 2021 00:00:00 +0000

상태 패턴(State Pattern)

GoF 디자인 패턴 중 행동 패턴에 해당한다.
상태 패턴은 객체가 가지고 있는 내부 상태에 따라 스스로 행동을 변경할 수 있게 하는 패턴이다. 상태를 표현하는 추상 클래스나 인터페이스를 만들고, 상태 객체를 내부에 가지게 된다.

사용법

객체의 행동이 상태에 따라 달라질 수 있고, 객체 상태에 따라 런타임에 행동이 바뀌어야 할 때
상태에 따라 달라지는 분기 처리가 많을 때

구조

행동을 가진 객체 Context는 State의 인스턴스를 유지하고 관리한다.
상태별로 필요한 행동을 캡슐화하여 State_{추상클래스/인터페이스}를 정의한다.
ConcreteState_{서브클래스}들은 Context의 상태에 따라 처리되어야 할 실제 행동을 구현한다.

장점

상태에 따른 행동을 국소화하여 상태에 대한 행동을 별도 객체로 관리함
상태별로 객체를 만들어줌으로써 상태 변화를 명백하게 함¹

:bulb: 1: 상태를 내부 데이터 값으로만 표현하면 단지 상태 변수에 값을 할당하는 것에 불과함.

구현 시 주의할 점

상태 패턴 구현에 신경써야하는 부분 중 첫번째는 상태 전이를 결정하는 주체이다. 일반적으로는 ConcreteState 클래스들이 자신 다음에 나오는 상태가 무엇이고 상태 전이가 언제 될지를 정하도록 만든다. 이 방법의 단점으로는 ConcreteState 클래스가 자신 다음에 나오는 다른 ConcreteState를 알아야 해서 서브클래스들끼리 종속성이 생길 수 있다는 것이다.

두번째는 상태 객체의 생성과 소멸 시점이다. (1)상태 객체를 필요할 때만 생성하고 필요없으면 없애는 방법과 (2)미리 만들어 놓고 계속 두는 방법이 있다. (1)의 방법은 상태 객체가 많은 정보를 담고 있는 경우에 유용하다. (2)의 방법은 상태 변화가 수시로 일어날 때 좋은 방법이다.

예제

클래스 다이어그램

구현

HandHeldFan handHeldFan = new HandHeldFan();
System.out.println("손풍기 샀다!! 작동 시켜볼까?\n");
for(int i=0;i<6;i++){
    System.out.print("딸깍 -> ");
    handHeldFan.clickButton();
}

[실행 결과]
손풍기 샀다!! 작동 시켜볼까?

딸깍 -> 약한 바람이 부는 중입니다.. 휘잉..
딸깍 -> 강한 바람이 부는 중입니다!!! 휘잉!! 휘잉!! 휘이잉!!!!
딸깍 -> 손풍기가 작동 중이 아닙니다.
딸깍 -> 약한 바람이 부는 중입니다.. 휘잉..
딸깍 -> 강한 바람이 부는 중입니다!!! 휘잉!! 휘잉!! 휘이잉!!!!
딸깍 -> 손풍기가 작동 중이 아닙니다.

소스 코드

전체 소스 코드

package main;

import fan.HandHeldFan;

public class Main {
    public static void main(String[] args) {
        HandHeldFan handHeldFan = new HandHeldFan();
        System.out.println("손풍기 샀다!! 작동 시켜볼까?\n");
        for(int i=0;i<6;i++){
            System.out.print("딸깍 -> ");
            handHeldFan.clickButton();
        }
    }
}

package fan.state;

import fan.HandHeldFan;

public interface State {
    void wind(HandHeldFan fan);
}

package fan;

import fan.state.State;
import fan.state.WeakState;

public class HandHeldFan {
    private State state;

    public HandHeldFan() {
        changeState(WeakState.getInstance());
    }

    public void clickButton() {
        state.wind(this);
    }

    public void changeState(State state){
        this.state = state;
    }
}

package fan.state;

import fan.HandHeldFan;

public class OffState implements State {
    private static OffState _instance;

    public static OffState getInstance() {
        if (_instance == null)
            _instance = new OffState();
        return _instance;
    }

    @Override
    public void wind(HandHeldFan fan) {
        System.out.println("손풍기가 작동 중이 아닙니다.");
        fan.changeState(WeakState.getInstance());
    }
}

package fan.state;

import fan.HandHeldFan;

public class WeakState implements State{
    private static WeakState _instance;

    public static WeakState getInstance() {
        if (_instance == null)
            _instance = new WeakState();
        return _instance;
    }

    @Override
    public void wind(HandHeldFan fan) {
        System.out.println("약한 바람이 부는 중입니다.. 휘잉..");
        fan.changeState(StrongState.getInstance());
    }
}

package fan.state;

import fan.HandHeldFan;

public class StrongState implements State{
    private static StrongState _instance;

    public static StrongState getInstance() {
        if (_instance == null)
            _instance = new StrongState();
        return _instance;
    }
    @Override
    public void wind(HandHeldFan fan) {
        System.out.println("강한 바람이 부는 중입니다!!! 휘잉!! 휘잉!! 휘이잉!!!!");
        fan.changeState(OffState.getInstance());
    }
}

:bookmark: REFERENCE
에릭 감마 외 3명, 「GoF의 디자인 패턴」, 피어슨에듀케이션코리아

[번역] 안드로이드 라이프사이클 모음 - (4) ViewModels, Translucent Activities, Launch Modes

Sat, 10 Jul 2021 00:00:00 +0000

:bulb: 원문 The Android Lifecycle cheat sheet — part IV : ViewModels, Translucent Activities and Launch Modes을 번역한 글입니다.

(4) ViewModels, Translucent Activities, Launch Modes

1. ViewModel

ViewModel에는 onCleared라는 하나의 콜백만 존재하므로 생명주기가 간단하다. 다만 Activity와 Fragment 사이에서의 차이점은 존재한다.

초기화는 ViewModel을 획득했을 때 일어나는데, 일반적으로 onCreate에서 수행된다.

2. Translucent Activities

Translucent Activity란 반투명 상태의 Activity이다. 반투명한 배경으로 아래에 뭐가 있는지 볼 수 있다.

Activity 테마에 android:windowIsTranslucent 속성이 적용되면, 다이어그램은 가볍게 변한다. 밑에 깔려있는 Activity는 stop되지 않고 pause만 되며 계속해서 UI를 업데이트할 수 있다.

또한, 홈에 갔다가 다시 돌아오면, 두 Activity 모두 restore, start 상태를 거치게 되고, Translucent Activity만 Resume된다.

3. Launch Modes

Task나 Back Stack을 다루는 것은 보통 권장하지 않는다. 기본으로 정의된 행동에 따라야 한다. 더 자세한 건 이 포스트를 참고해라.

만약 정말로 SINGLE_TOP을 사용해야 한다면, 다이어그램은 다음과 같이 된다.

비교를 위해 singleTask의 다이어그램도 보여주겠지만, 아마 사용할 일은 없을 것이다.

👉 주목! 만약 Jetpack의 Navigation을 사용하면 Single Top을 지원받을 수 있고 자동으로 통합된 백 스택을 사용할 수 있다.

비교

ViewModel

Translucent Activities

Launch Modes

:bookmark: REFERENCE
The Android Lifecycle cheat sheet — part IV : ViewModels, Translucent Activities and Launch Modes

[번역] 안드로이드 라이프사이클 모음 - (3) Fragment

Mon, 21 Jun 2021 00:00:00 +0000

:bulb: 원문 The Android Lifecycle cheat sheet — part III : Fragments을 번역한 글입니다.

(3) Fragment

상황 1. Activity와 Fragment의 시작과 종료

Activity의 onCreate는 Fragment의 Lifecycle 이전에 실행됨
onStart나 onResume 같이 병행으로 되어있는 것은 Activity가 먼저 실행될수도, Fragment가 먼저 실행될 수도 있음
- EX) Activity의 onStart -> Fragment의 onStart -> Fragment의 onResume -> Activity의 onResume 순서로 실행될 수 있음
각각의 실행 순서를 관리함으로써 Race Condition을 피할 수 있어야 함

상황 2. Activity와 Fragment의 회전

👉 상태 관리하기

Fragment는 Activity와 비슷하게 저장/복원된다.
Fragment에는 onRestoreInstanceState가 없다는 차이점이 있지만, onCreate, onCreateView, onActivityCreated에서는 Bundle을 사용할 수 있다.

상황 3. Activity와 retained Fragment의 회전

Fragment는 구성 변경 시에 같은 인스턴스를 사용할 수 있다. 이러한 상태를 Fragment가 retain 됐다고 한다.

Activity가 재생성된 후에는 같은 Fragment의 Instance가 사용되기 때문에, 회전 후에 해당 Fragment는 소멸되지도 새로 생성되지도 않는다. 다만 여전히 onActivityCreated에서 Bundle을 쓸 수 있다.

Retained Fragment는 구성 변경을 위한 데이터 저장을 위한 경우가 아니라면 사용하지 않는 것이 좋다.

비교

:bookmark: REFERENCE
The Android Lifecycle cheat sheet — part III : Fragments

SOLID 원칙 - (5) 의존 역전 원칙 (DIP)

Fri, 18 Jun 2021 00:00:00 +0000

(5) 의존 역전 원칙 (DIP)

👴 Depend in the direction of abstraction. High level modules should not depend upon low level details.

SOLID의 마지막 원칙인 의존 역전 원칙은 저수준 모듈이 고수준 모듈에 의존해야 한다는 것이다. UML에서 추상화의 방향은 저수준 -▷ 고수준으로 되어있다. Depend in the direction of abstraction이라는 말은 이러한 방향을 따라야 한다는 말인 것 같다. 이렇게 한다면 저수준의 모듈이 변경되더라도 고수준 모듈은 변경될 필요가 적어진다.
그렇다면 고수준과 저수준이란 말의 의미는 무엇일까? 통상적으로 고수준은 의미 있는 기능을 제공하는 모듈을 말하고 저수준은 고수준의 모듈을 제공하기 위해 필요한 모듈을 말한다.
고수준이 저수준에 의존하지 않고, 저수준이 고수준에 의존하게 하는 것은 추상화를 통해 실현할 수 있다. 아래 예시를 보자.

DIP 예시

OCP와 LSP에서의 예시와 비슷한 예시를 이용해보자.

(상황 ) 롤에서 한타라는 중요한 순간에 스킬 콤보를 넣는 것은 중요하다. 하지만 캐릭터마다 스킬이 다르기때문에 콤보도 다 다르다. 따라서 캐릭터마다 콤보를 다 다르게 설정해주어야 한다.

EX1) 고수준이 저수준에 의존하는 경우

첫번째로 한타라는 고수준 모듈이 캐릭터라는 저수준 모듈에 의존한다고 해보자.

public void 한타(Character character) {
      if(character instanceof 야스오){
          character.Q(); character.E(); character.Q(); character.R();
      }
      else if(character instanceof 탈론){
          character.W(); character.Q(); character.R();
      }
      else {
          ...
      }
  }
}

고수준이 저수준에 의존하고 있으므로 저수준 모듈이 추가될때마다 고수준 모듈은 계속 변경되어야 한다. 위와 같은 코드에서 캐릭터가 100명이 추가된다고 하면 if-else 블록이 100개가 되는 것이다.

EX2) 저수준이 고수준에 의존하는 경우

저수준이 고수준에 의존하도록 바꾼다면 어떻게 될까? 앞서 말했듯 추상화를 이용했다. 인터페이스를 이용해 추상화하는 방법과 추상클래스를 이용해 추상화하는 방법 두가지를 사용해보았다.

// 1. 인터페이스 이용
public interface Combo() {
		public void combo();
}
public class Character implements Combo {}
public class 야스오 extends Character {}
public class 탈론 extends Character {}

// 2. 추상 클래스 이용
public abstract class Character {
		public abstract void combo();
}
public class 야스오 extends Character {}
public class 탈론 extends Character {}

// 고수준 모듈
public void 한타(Character character) {
		character.combo();
}

이제 캐릭터라는 저수준 모듈이 변경되어도 한타라는 고수준 모듈은 변경될 필요가 없다. 결국 기능의 변경으로 인해 그 기능을 이용하는 곳의 변경은 최소화해야 한다는 개방 폐쇄 원칙과도 관련이 있다.

❗ 주의 ❗ 런타임에서의 의존이 바뀌는 것은 아니다

다만 주의할 점으로는 런타임에서의 모듈간의 의존 방향이 바뀌는 것은 아니라고 한다. 의존 역전 원칙은 소스코드의 의존을 역전시켜서 프로그래머가 변경에 유연하게 대처할 수 있도록 하는 원칙이지, 런타임에서의 의존을 역전시키는 것은 아니다.

결론

SOLID 원칙에서 SRP, ISP와 LSP, IDP, OCP는 묶어서 볼 수 있다.

SRP와 ISP는 객체의 크기가 커지지 않도록 한다. 한 곳에서의 변경이 다른 곳에 미치는 영향을 최소화한다.
LSP, IDP는 OCP를 지원한다. 추상화와 다형성을 이용해 기능을 확장하면서도 기존 코드의 수정을 최소화한다.

다만 SOLID 원칙은 소스코드를 사용하는 사용자 입장에서의 기능 사용에 중점을 둔다. LSP는 사용자에게 기능 명세를 제공한다. ISP는 클라이언트 입장에서 인터페이스를 분리한다. DIP는 고수준 모듈 입장에서 추상화를 도출해낸다.

SOLID 원칙을 잘 지켜서 프로그래밍 해보도록 하자..!😤

:bookmark: REFERENCE
최범균, 「개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴」, 인투북스
Solid Relevance

[번역] 안드로이드 라이프사이클 모음 - (2) Multiple Activities

Mon, 07 Jun 2021 00:00:00 +0000

:bulb: 원문 The Android Lifecycle cheat sheet — part II: Multiple activities을 번역한 글입니다.

(2) Multiple Activities

여러 컴포넌트의 Lifecycle을 표현할 때 다이어그램을 사용했지만, 각 그룹 사이의 호출 순서는 다를 수 있다. 각 그룹 내에서의 순서에만 주목하면 된다. 또한 custom launch mode나 task에서는 적용되지 않는다.

상황 1. 백스택 - Activity 간 이동

새로운 액티비티가 시작되면, Activity 1은 사용자가 홈 버튼을 눌렀을 때와 비슷한 상황을 겪게 된다.

뒤로가기 버튼이 눌리면 Activity 2는 소멸(destroy)되고 끝난다(finish).

👉 상태 관리하기

onSaveInstanceState는 호출되지만 onRestoreInstanceState는 호출되지 않는다. Activity :2에서 구성 변경이 일어나면 Activity 1는 포커스를 다시 얻었을 때 소멸되고 다시 생성될것이다. 그래서 상태를 저장하는 것이 중요하다.

상황 2. 백스택 - 구성이 변경됐을 때 백스택에 있는 Activity

👉 상태 관리하기

상태를 저장하는 것은 Activity가 foreground에 있을 때에만 중요한 게 아니다. 스택에 존재하는 모든 Activity는 구성 변경 후 UI를 다시 생성할 때 상태 복원이 필요하다.

또한, 시스템이 앱의 프로세스를 언제든지 kill할 수 있기 때문에 어떠한 상황에서는 상태를 복원할 준비가 되어있어야 한다.

상황 3. 백스택 - 앱 프로세스가 kill될 때

Android OS는 자원이 부족하면 백그라운드에 있는 앱을 kill한다.

👉 상태 관리하기

백스택의 상태를 저장되지만, 자원을 효율적으로 관리하기 위해 Activity가 재생성될 때에만 상태를 복원(onRestoreInstanceState)한다.

비교

:bookmark: REFERENCE
The Android Lifecycle cheat sheet — part II: Multiple activities

SOLID 원칙 - (4) 인터페이스 분리 원칙 (ISP)

Fri, 04 Jun 2021 00:00:00 +0000

(4) 인터페이스 분리 원칙 (ISP)

👴 Keep interfaces small so that users don’t end up depending on things they don’t need.

SOLID의 4번째 원칙인 인터페이스 분리 원칙은 인터페이스는 인터페이스를 사용하는 클라이언트 기준으로 분리해야한다 라는 것이다. 인터페이스를 구체적으로 분리해서 자신과 관련없는 메소드는 구현하지 않아야 한다.

ISP를 어기는 경우

인터페이스 분리 원칙을 위반했을 때 발생하는 문제점 중 가장 유명한 예시는 소스 재컴파일 문제이다.

소스 재컴파일

C, C++, Go, Swift, Java는 정적 언어이다. 정적 언어란 변수의 자료형이 컴파일 타임에 결정되는 언어이다. 반대로 동적 언어는 자료형이 런타임에 결정되며 예시로는 Python, Javascript, Ruby 등이 있다. 정적 언어의 경우 한 곳에서의 변경만으로 전체 소스코드를 다시 컴파일해야 한다.

EX1) ISP 위반 예시

(상황 ) 복합기에 print(), copy(), fax() 메소드가 있다. 프린터는 print()를, 복사기는 copy()를, 팩스는 fax()를 사용한다. 세 가지 메소드는 같은 파일에 존재하므로, 프린터의 print()로직만 바뀌어도 복사기와 팩스도 재컴파일을 해야 한다.

👊 인터페이스를 분리해서 해결하자 👊

위와 같은 경우는 인터페이스를 클라이언트 기준으로 나누지 않아서 인터페이스 분리 원칙을 위반하였다. 인터페이스 분리 원칙을 지키려면 인터페이스를 분리하면 된다!! 그럼 인터페이스를 분리하는 기준은? 앞서 말했던 클라이언트를 기준으로 분리하면 된다.

클라이언트는 자신이 사용하는 메소드를 가지는 인터페이스만 구현하도록 한다. 인터페이스를 분리하면 프린터의 print() 로직이 바뀌어도 복사기와 팩스는 영향을 받지 않는다.

결론

인터페이스 분리 원칙은 단일 책임 원칙과도 관련이 있다. 인터페이스 분리 원칙도 한 곳의 변경이 다른 곳에 미치는 영향을 최소화한다. 따라서 클래스가 가지는 책임을 최소화하고 인터페이스를 분리해서 클래스를 설계해야 한다.

:bookmark: REFERENCE
최범균, 「개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴」, 인투북스
Solid Relevance
[소프트웨어 설계] 인터페이스 분리 원칙(ISP-Interface Segregation Principle)

[번역] 안드로이드 라이프사이클 모음 - (1) Single Activity

Tue, 01 Jun 2021 00:00:00 +0000

:bulb: 원문 The Android Lifecycle cheat sheet — part I: Single Activities을 번역한 글입니다.

개요

사용자는 앱을 이용하면서 화면을 돌리거나, 알림에 반응하거나, 다른 일을 하게되는데, 이런 이벤트가 발생한 뒤에도 사용자는 앱을 원활하게 사용할 수 있어야 한다.

이러한 UX를 제공하려면 컴포넌트의 Lifecycle을 관리할 줄 알아야 한다. 컴포넌트는 Activity, Fragment, Service나 앱 그자체, 혹은 기본 프로세스일 수 있다. 컴포넌트들은 Lifecycle을 가지고 있고, Lifecycle동안 상태가 변한다. 시스템은 Lifecycle Callback Method를 통해 앞서 말한 상태의 변화를 우리에게 알려준다.

(1) Single Activity

상황 1. 앱 종료(finish) 및 재시작(restart)

👉 일어나는 경우

사용자가 뒤로가기 버튼을 누르거나
Activity.finish()가 호출될 때

👉 상태 관리하기

onSaveInstanceState는 호출되지 않는다. (Activity가 종료되므로 상태를 저장할 필요 없음)
앱이 종료되면 복원할 상태가 없기때문에, 앱이 재시작될 때 onCreate는 Bundle을 가지고 있지 않는다.

상황 2. 사용자가 다른 곳으로 이동

👉 일어나는 경우

사용자가 홈 버튼을 누르거나
다른 앱으로 이동했을 때

시스템은 앱을 중지(Stop)하지만, 바로 끝내(finish)지는 않는다.

👉 상태 관리하기

Activity가 중지 상태에 들어가면, 시스템이 앱 프로세스를 kill할 경우에 대비해 onSaveInstanceState를 통해 앱의 state를 저장한다.

프로세스가 kill되지 않았을 경우, Activity의 인스턴스는 모든 State를 보유한 채로 메모리에 남아있게 된다. Activity가 foreground 상태로 돌아오면, Activity는 이전의 정보들을 다시 초기화할 필요없이 이미 생성했던 정보를 다시 불러오면 된다.

상황 3. Configuration이 바뀜

👉 일어나는 경우

회전과 같은 구성 변경이 일어나거나
사용자가 멀티 윈도우 기능을 통해 윈도우 크기를 조정하는 경우

👉 상태 관리하기

회전이나 윈도우 크기 변화 같은 구성 변경이 일어나도 사용자가 중단했던 시점부터 계속할 수 있도록 해야 한다.

Activity는 destroy되지만, state는 저장되고 새로운 인스턴스에 복원된다.
onCreate의 Bundle과 onRestoreInstanceState의 Bundle은 같다.

상황 4. 앱이 시스템에 의해 일시 중지(pause)될 때

👉 일어나는 경우

멀티 윈도우 기능 도중 포커스를 잃을 때
다른 앱이 현재 실행 중인 앱 위를 부분적으로 덮을 때 (구매 다이알로그, 런타임 퍼미션 다이알로그, 로그인 다이알로그…)
공유 다이알로그같은 intent 선택기가 나타난 경우

❌ 이런 경우는 일어나지 않아요

같은 앱의 다이알로그 (AlertDialog나 DialogFragment)
Notification (사용자가 새로운 Notification을 받거나 Notification Bar를 내렸을 때)

에는 Activity가 일시중지 되지 않는다.

비교

:bookmark: REFERENCE
The Android Lifecycle cheat sheet — part I: Single Activities

SOLID 원칙 - (3) 리스코프 치환 원칙 (LSP)

Mon, 31 May 2021 00:00:00 +0000

(3) 리스코프 치환 원칙 (LSP)

👴 A program that uses an interface must not be confused by an implementation of that interface.

말이 너무 어렵다! 보통은 이렇게 말하는 것 같다. 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

리스코프 치환 원칙은 기능 확장과 함수의 명세와 관련된 원칙이다. 또한 리스코프 치환 원칙을 어기면 개방 폐쇄 원칙을 위반할 가능성이 높아진다.

SOLID 원칙 - (2) 개방 폐쇄 원칙 (OCP)에서의 예시를 보자.

public class Character {
    public void fight() {
        combo();
    }
    protected void combo() {
				Q(); W(); E(); R();
    }
}

public void 한타(Character character) {
		character.fight();
}

위와 같은 한타() 메소드를 사용할 때, Character를 상속받은 야스오나 티모를 한타()의 파라미터로 전달해도 한타 메소드는 잘 동작해야한다는 원칙이다.

한타(new 야스오());
한타(new 티모());

LSP를 어기는 경우

리스코프 치환 원칙을 위반하는 경우에는 두 가지 경우가 있다.

EX1) 계약 위반

첫번째는 계약 위반이다. 함수를 사용할 때 아래와 같이 정해진 계약 혹은 명세를 지키지 않는 경우다.

이상한 값 리턴
이상한 기능 수행
이상한 Exception 발행

이상한 기능을 수행하는 경우

(상황 ) 티모는 롤 캐릭터 중 하나이다. 롤 캐릭터는 한타 때 적극적으로 싸워야한다. 스킬 콤보를 넣는 fight() 메소드를 이용해서 싸우려고 한다. 근데 티모라는 캐릭터는 싸우지않고 점멸을 이용해서 혼자 뒤로 뺀다.

티모는 롤 캐릭터이면서도 이상한 기능을 수행한다.

public class 티모 extends Character {}

public void 한타(Character character) {
    if(character instanceof 티모){
        점멸(); //팀원들 다 싸우고 있는데 혼자 뒤로 빼는거
    }
    else {
        character.fight();
    }
}

이상한 Exception을 발행하는 경우

(상황 ) 앞서 말했듯이 한타 때 스킬 콤보를 넣으면서 싸워야한다. 근데 티모는 “나는 콤보 없는데용?ㅋ”하며 이상한 Exception을 발행한다.

public void 한타(Character character) {
    if(character instanceof 티모){
        throw new ComboNotExistException(); //나는 콤보 없는데용?
    }
    else {
        character.fight();
    }
}

위와 같은 예시가 리스코프 치환 원칙을 위반한 경우다. 티모는 상위 타입인 Character를 상속받았음에도 불구하고 Character를 사용하는 한타 메소드에서 제대로 동작하지 않는다. 제대로 동작하려면 추가적인 처리가 필요하다.

LSP를 지키도록 하려면?

따라서 티모는 상위 타입인 Character를 대체할 수 없다고 판단하고 Character가 아닌 Troll을 상속받는다.

// 티모는 정상적인 캐릭터가 아니라 트롤이라고 가정합니다
public class 티모 extends Troll {}

EX2) 확장 위반

확장을 하는데, 확장함으로써 기존 코드를 수정해야 하는 경우다. 상위타입만으로 프로그래밍을 할 수 없기 때문이다.

(상황 ) 사실상 티모는 스킬 콤보가 딱히 없다. 그냥 기본공격(평타)으로 패면 된다.

// 기존 코드
public void 한타(Character character) {
		character.fight();
}

// 티모라는 새로운 캐릭터가 추가됨
public void 한타(Character character) {
    if(character instanceof 티모){
        기본공격();
    }
    else {
        character.fight();
    }
}

한타에 스킬 콤보를 넣어서 싸워야 하는데, 스킬 콤보가 없는 티모라는 캐릭터가 생겼기때문에 티모는 콤보 없이 기본공격만 하겠다는 코드를 새롭게 추가해주어야한다.

만약 콤보가 없는 새로운 캐릭터가 또 추가된다면 기존 코드는 계속 수정해주어야 한다.

public void 한타(Character character) {
  if(character instanceof 티모1){
      기본공격();
  }
	else if(character instanceof 티모2){
      기본공격();
  }
  else {
      character.fight();
  }
}

🤔 그럼 어떻게 해결할 수 있을까? 🤔

답은 추상화다!

변경되는 부분을 새롭게 추상화시키면 된다. 기존 코드에서 isComboExist() 메소드가 추가됐고, Character를 사용하던 한타 메소드에서는 isComboExist()를 이용하면 된다.

스킬 콤보가 없는 새로운 티모1, 티모2, 티모3, … 이 추가되더라도 기존 코드는 바뀔 필요가 없다.

public class Character {
  public void fight() {
      combo();
  }
  protected void combo() {
  		Q(); W(); E(); R();
  }
  protected boolean isComboExist() {
  		return true;
  }
}

public class 티모 extends Character{
  @Override
  protected boolean isComboExist() {
  		return false;
  }
}

public void 한타(Character character) {
  if(character.isComboExist()){
      character.fight();
  }
  else {
      기본공격();
  }
}

결론

리스코프 치환 원칙은 개방 폐쇄 원칙과 관련되어 있다. 리스코프 치환 원칙을 어긴다면 확장 시 기존 코드를 계속 수정해주어야 한다. 이는 '확장에는 열려있고 변경에는 닫혀있어야 한다' 라는 개방 폐쇄 원칙의 개념에 위반된다. 따라서 리스코프 치환 원칙은 기능 확장을 쉽게 하는 것이 주된 목표인 것 같다.

:bookmark: REFERENCE
최범균, 「개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴」, 인투북스
Solid Relevance

SOLID 원칙 - (2) 개방 폐쇄 원칙 (OCP)

Thu, 27 May 2021 00:00:00 +0000

(2) 개방 폐쇄 원칙 (OCP)

👴 A Module should be open for extension but closed for modification

말은 제일 쉽다. 확장에는 열려있어야 하고, 변경에는 닫혀있어야 한다. 어떠한 기능을 변경하거나 확장하면서, 그 기능을 사용하는 기존 코드의 수정을 최소화한다는 것이다. 개방 폐쇄 원칙의 핵심은 변경이 예상되는 곳을 추상화하고 다형성을 이용하는 것이다. 개방 폐쇄 원칙을 적용하는 방법은 대표적으로 두 가지가 있다.

OCP 적용 방법

EX1) OCP 적용 방법 : 추상화

(상황 ) 롤의 스킬은 Q,W,E,R로 구성되어 있다¹. 슬기는 게임을 할 때 각 캐릭터별로 구현된 Q,W,E,R 스킬을 누르면서 게임을 한다.

(추상화 ) 여기서 스킬 Q,W,E,R을 Character라는 인터페이스로 추상화시켰다². 야스오와 티모는 Character 인터페이스를 구현한다. 슬기는 야스오와 티모를 플레이할 때 Q,W,E,R을 클릭한다.

만약 새로운 캐릭터인 그웬을 추가하는 경우(확장) 이미 추상화한 Character를 구현하면 된다. 하지만 슬기는 기존과 동일하게 그웬을 플레이할 때 Q,W,E,R을 누르는 것은 변함없다!(기존 코드 변함 없음)

:bulb: 1 사실 더 있다.
:bulb: 2 명답은 아닌 것 같다. 인터페이스를 이용할 거면 Skill이라는 인터페이스로 만들거나 Character내에 QWER을 추상메소드로 만들어서 상속받는 방법이 더 나을 것 같지만.. 귀찮으니 그냥 패스한다.

EX2) OCP 적용 방법 : 상속

(상황 ) 롤을 할 때 가장 중요한 것이 있다. 바로 한타라는 중요한 순간에 스킬 콤보를 넣는 것이다. 하지만 캐릭터마다 스킬이 다르므로 스킬 콤보도 다 다르다. 슬기는 롤린이라 캐릭터 스킬은 다 모르지만 항상 스킬 콤보를 넣고 싶다! fight()라는 메소드만을 호출함으로써 캐릭터별로 알맞은 콤보를 넣으면 어떨까?

(상속 ) 개방 폐쇄 원칙을 상속을 통해 적용하기 위해 템플릿 메소드 패턴을 사용할 것이다. 오버라이딩할 상위 클래스의 메소드에 접근 제어자를 protected로 설정한다.

슬기는 한타 때 fight() 메소드를 호출하면되고, fight()내에선 스킬 콤보를 사용해 줄 combo() 함수를 사용한다.

public class Character {
    public void fight() {
        combo();
    }
    protected void combo() {
				Q(); W(); E(); R();         //대충 기본 콤보라 가정
    }
}

public class 야스오 extends Character{
    @Override
    protected void combo() {
        E(); Q(); E(); Q(); R();    //야스오 안 써서 사실 모름
    }
}

Character를 상속받은 야스오는 combo()를 오버라이딩해서 야스오에 맞는 스킬 콤보를 재정의한다.

public void 한타(Character character) {
		character.fight();
}

슬기는 야스오의 콤보가 정확히 어떤 것인지 알 필요없이 fight()만을 호출하면 알아서 해당 캐릭터에 맞게 콤보를 적용할 수 있다! ~~MVP SSAP가능~~

OCP가 깨졌을 때의 주요 증상

그렇다면 개방 폐쇄 원칙을 잘 지켰는지 확인하는 방법을 무엇일까? 개방 폐쇄 원칙이 깨졌을 때의 주요 증상들을 확인하면 된다.

EX1) 다운 캐스팅

개방 폐쇄 원칙이 깨졌을 때의 주요 증상 중 하나로는 다운캐스팅이다. 추상화를 제대로 시키지 않은 경우 다음과 같이 다운캐스팅이 일어난다. 야스오일땐 이 콤보, 티모일땐 이 콤보, ….

만약 여기서 새로운 캐릭터들이 계속 추가된다면 각 클래스의 타입마다 다운캐스팅을 해주어야 한다.

public void 한타(Character character) {
    if(character instanceof 야스오){
        E(); Q(); E(); Q(); R();
    }
    else if(character instanceof 티모){
        R(); R(); R();
    }
    else {
        ...
    }
}

EX2) 비슷한 if-else 구문

두번째 증상은 비슷한 if-else 구문이 많아진다는 것이다.

(상황 ) 롤 캐릭터는 직업군별로 가지고 있는 기본 스탯이 다르다. 기본적으로 체력은 가지지만 직업마다 마나, 기력, 분노 등을 다르게 가지고 있다. 나는 캐릭터의 기본 스탯을 초기화하는 코드를 작성하고 싶다. 근데 캐릭터 직업군별로 다르게 스탯을 설정하고 싶다! 처음 작성한 코드는 다음과 같다.

private int characterType;

public void initialize() {
    if(characterType==1) {
        health = 100;
        mana = 100;
        energy = 0;
        fury = 0;
    }
    else if(characterType==2){
        health = 100;
        mana = 0;
        energy = 100;
        fury = 0;
    }
    else {
        ...
    }
		...
		// 초기화 로직
}

비슷한 if-else 구문이 반복된다. if-else 블록 내에 들어가는 부분을 추상화시킨다면 코드가 좀 더 깔끔해질 것 같다.

private CharacterType characterType;

public void initialize() {
    int health = characterType.getHealth();
    int mana = characterType.getMana();
    int energy = characterType.getEnergy();
    int fury = characterType.getFury();
    ...
		//초기화 로직
}

(추상화 ) 중복되는 부분을 CharacterType으로 추상화시켰다. 각 직업군별로 스탯을 다르게 설정하고 싶으면 CharacterType을 구현하면 된다. 코드를 사용하는 경우에는 중복된 코드를 작성할 필요가 없어져 코드가 훨씬 간결해진다.

결론

개방 폐쇄 원칙은 코드 변경의 유연함과 관련되어 있다. 가장 핵심은 기능을 확장해도 기존 코드의 수정을 최소화하는 것이다. 또한 SOLID에서의 리스코프 치환 원칙과 의존 역전 원칙은 개방 폐쇄 원칙을 지원한다. 아마 다음 포스팅에서 나올 것이다.

:bookmark: REFERENCE
최범균, 「개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴」, 인투북스
Solid Relevance

SOLID 원칙 - (1) 단일 책임 원칙 (SRP)

Wed, 26 May 2021 00:00:00 +0000

(1) 단일 책임 원칙 (SRP)

👴 Gather together the things that change for the same reasons. Separate things that change for different reasons.

마틴 아저씨는 위와 같이 말했다. 같은 이유로 변하는 애들을 모아라. 다른 이유로 변하는 애들은 분리해라. 객체 지향에 대입해보면, 클래스에는 단 한 가지의 책임을 할당해야하고, 클래스를 변경하는 이유는 단 한 개여야 한다는 말이다.

객체 지향의 기본은 객체에 책임을 할당하는 데에 있다. 객체가 가지는 책임(역할)이 많아질수록 한 책임에서의 변화가 다른 곳에 미치는 영향은 증가할 것이다. 이는 결국 유지보수의 어려움까지 이어진다.

EX1) 유지보수 관점에서의 SRP

(상황 ) 도서관 대출 서비스가 있다. 시민의 정보에 따라 책을 대출해주는 서비스이다.

Librarian이라는 사서는 월급도 쥐꼬리만큼 받는데 여러 가지의 책임을 갖는다.

1. 서버에서 데이터 가져옴
2. 가져온 데이터를 파싱함
3. 시민이 대출 가능한지 여부 확인 (연체일수가 0이면 대출 가능)
4. 대출

서버에서 보내주는 데이터와, Librarian의 코드는 다음과 같다.

{
	name : "Seulgi Kim",
	late : 2
}

public class Librarian {
    public void reserve(){
        // 1. 네 고객님.. 성함이..?
        Scanner scanner = new Scanner(System.in);
        String name = scanner.nextLine();

        // 2. 네 잠시만요.. 타닥타닥.. 서버에서 시민의 정보 가져옴
        String data = connectToServer(name);
        int late = getLate(data);

        // 3. 대출 여부 확인
        if(late == 0) {
            // 4. 대출
            System.out.println("대출 가능합니다.");
        }
        else {
            System.out.println("대출은 무슨!");
        }
    }
    public String connectToServer(String name){
        /* get data from server */
        /* 데이터 가져오는 코드가 존재한다고 가정 */
        return "{ name : \"Seulgi Kim\"," +
                " lateDate : 2 }";
    }
    public int getLate(String data){
        /* parse logic */
        /* 파싱 로직 존재한다고 가정 */
        return 2;
    }
}

:heavy_exclamation_mark: 여기서 만약 서버에서 보내주는 데이터가 변경되면? :heavy_exclamation_mark:

서버에서 보내주는 데이터가 int에서 boolean으로 바뀌었다고 가정하자.

{
	name : "Seulgi Kim",
	late : true
}

그렇다면 Librarian의 코드는 다음과 같이 바뀐다.

public class Librarian {
    public void reserve(){
        // 1. 네 고객님.. 성함이..?
        Scanner scanner = new Scanner(System.in);
        String name = scanner.nextLine();

        // 2. 네 잠시만요.. 타닥타닥.. 서버에서 시민의 정보 가져옴
        String data = connectToServer(name);
        boolean late = getLate(data);

        // 3. 대출 여부 확인
        if(!late) {
            System.out.println("대출 가능합니다.");
        }
        else {
            System.out.println("대출은 무슨!");
        }
    }
    public String connectToServer(String name){
        /* get data from server */
        /* 데이터 가져오는 코드가 존재한다고 가정 */
        return "{ name : \"Seulgi Kim\"," +
                " lateDate : true }";
    }
    public boolean getLate(String data){
        /* parse logic */
        /* 파싱 로직 존재한다고 가정 */
        return true;
    }
}

바뀐 부분

데이터 파싱 로직
대출 여부 확인 로직

등이 바뀌었다.

Librarian이 여러 책임을 가지고 있었기 때문에 한 책임에서의 변화가 다른 책임에게도 영향을 준 것이다.

😆 친구들에게 이 예시를 보여줬더니, 사서가 고생할 필요없이 데이터 형식을 바꾼 서버 개발자를 까면 된다고 했다 😆

🤔 해결) 만약 아르바이트를 고용해서 책임을 나눠준다면? 🤔

사서는 더 이상 참을 수 없어서 아르바이트를 고용했다. 자신의 일부 책임을 분리해서 알바한테 시키기로 했다.

Librarian 사서의 책임

1. 대출

PartTimeJob 알바의 책임

1. 서버에서 데이터 가져옴
2. 가져온 데이터를 파싱함
3. 시민이 대출 가능한지 여부 확인

public class PartTimeJob {
    private String connectToServer(String name){
        /* get data from server */
        return "{ name : \"Seulgi Kim\"," +
                " lateDate : true }";
    }
    private boolean getLate(String data){
        /* parse logic */
        return true;
    }
		// 네ㅠㅠ 이 사람 대출 가능한지 여부 보내드립니다..
    public boolean check(String name) {
        String data = connectToServer(name);
        boolean late = getLate(data);
        return late;
    }
}

public class Librarian {
    public void reserve(){
        // 1. 네 고객님 ^^ 성함이 어떻게 되세요? ^^
        Scanner scanner = new Scanner(System.in);
        String name = scanner.nextLine();

        // 2. 야 알바! 데이터 가져와
        PartTimeJob arbeit = new PartTimeJob();
        boolean isReservationAvailable = arbeit.check(name);

        // 3. 대출해드릴게요~
        if(isReservationAvailable){
            System.out.println("대출 가능합니다.");
        }
        else {
            System.out.println("대출은 무슨!");
        }
    }
}

위와 같이 책임을 분리했다. 알바가 데이터를 관리하고, 사서는 대출만 해주는 것으로 바뀌었다. 사서는 이제 대출해주는 행위에만 신경쓰면 된다!!

😝 만약 데이터 형식이 bool -> int로 다시 바뀐다면? 😝

public class PartTimeJob {
    private String connectToServer(String name){
        /* get data from server */
        return "{ name : \"Seulgi Kim\"," +
                " lateDate : 2 }";
    }
    private int getLateDate(String data){
        /* parse logic */
        return 2;
    }
    public boolean check(String name) {
        String data = connectToServer(name);
        int lateDate = getLateDate(data);
        return lateDate == 0;
    }
}

public class Librarian {
    public void reserve(){
        // 1. 네 고객님 ^^ 성함이 어떻게 되세요? ^^
        Scanner scanner = new Scanner(System.in);
        String name = scanner.nextLine();

        // 2. 야 알바! 데이터 가져와
        PartTimeJob arbeit = new PartTimeJob();
        boolean isReservationAvailable = arbeit.check(name);

        // 3. 대출해드릴게요~
        if(isReservationAvailable){
            System.out.println("대출 가능합니다.");
        }
        else {
            System.out.println("대출은 무슨!");
        }
    }
}

사서는 자신의 일을 바꿀 필요 없이 알바생만 죽어나면 된다! 👏

EX2) 재사용 관점에서의 SRP

(상황 ) 도서관 내에 새로운 직업이 생겼다. 도서관 문앞에 경호원 Bodyguard가 생겼고 경호원은 대출이 연체된 사람은 입장도 못하게 막는다!

도서관은 예산이 딸려서 알바를 고용하지 못한 상태다 ㅠㅠ

import java.util.Scanner;

public class BodyGuard {
    public void letIn(){
        // 1. 어서오세요.. 성함이?
        Scanner scanner = new Scanner(System.in);
        String name = scanner.nextLine();

        // 2. 네 잠시만요..
        String data = connectToServer(name);
        boolean lateDate = getLateDate(data);

        // 3. 입장 가능한지 확인
        if(!lateDate) {
            System.out.println("입장 가능합니다.");
        }
        else {
            System.out.println("나가!");
        }
    }
    public String connectToServer(String name){
        /* get data from server */
        return "{ name : \"Seulgi Kim\"," +
                " lateDate : true }";
    }
    public boolean getLateDate(String data){
        /* parse logic */
        return true;
    }
}

알바를 고용하지 않았으므로(책임을 분리하지 않았으므로) 아까 사서가 했던 일을 똑같이 그대로 해야한다.

:interrobang: 경호원이 알바한테 데이터 확인을 시킨다면? :interrobang:

public class BodyGuard {
    public void letIn(){
        // 1. 어서오세요~ 도서관입니다~ 성함이 어떻게 되세요?
        Scanner scanner = new Scanner(System.in);
        String name = scanner.nextLine();

        // 2. 야 알바! 데이터 가져와
        PartTimeJob arbeit = new PartTimeJob();
        boolean isEnterAvailable = arbeit.check(name);

        // 3. 연체일수가 없으면 입장 가능
        if(isEnterAvailable) {
            System.out.println("입장 가능합니다.");
        }
        else {
            System.out.println("나가!");
        }
    }
}

사서와 경호원 모두 알바를 재사용함으로써 코드는 감소한다!

결론

단일 책임 원칙은 변경의 여파를 줄이기 위해, 재사용을 용이하게 하기 위해 적용한다.

그렇다면 단일 책임 원칙은 어떻게 지켜요?

메소드를 실행하는 애들을 확인하면 된다.

B를 변경하는 경우 X만 변경되고, C를 변경하는 경우 Y만 변경된다면 A의 X책임과 Y책임을 분리하자!

:bookmark: REFERENCE
최범균, 「개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴」, 인투북스
Solid Relevance

객체지향 설계 원칙 : SOLID 원칙

Tue, 25 May 2021 00:00:00 +0000

애플리케이션 설계

애플리케이션은 한 번 구현하고 나면 변경 시에 많은 비용이 소요되기때문에 설계를 잘하는 것이 중요하다. 잘 설계된 애플리케이션은 유지보수나 안정성, 그리고 보안 등의 관점에서 많은 이점을 제공해준다. 따라서 처음에 애플리케이션을 제대로 설계하는 것이 아주 중요하다!

SOLID 원칙

그렇다면 애플리케이션 설계를 어떻게 하는게 좋을까? 검증된 애플리케이션 설계 방법은 없나?

있다! 바로 로버트 C. 마틴의 SOLID 원칙이다. SOLID 원칙은 변화에 유연하게 대처하기 위한 객체 지향의 기본 설계 원칙이다. 주된 목표는 (1)한 곳의 변경이 다른 곳에 미치는 영향을 최소화하고, (2)확장이 기존 코드에 미치는 영향을 최소화하는 것이다.

SOLID는 각 다섯 개 원칙의 앞글자를 따서 명명한 것이다. 다섯가지의 원칙은 아래와 같다.

단일 책임 원칙 (Single Responsibility Principle; SRP)
개방 폐쇄 원칙 (Open-Closed Principle; OCP)
리스코프 치환 원칙 (Liskov Substitution Principle; LSP)
인터페이스 분리 원칙 (Interface Segregation Principle; ISP)
의존 역전 원칙 (Dependency Inversion Principle; DIP)

다음 포스팅부터 하나씩 차례로 알아볼 예정이다.

:bookmark: REFERENCE
최범균, 「개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴」, 인투북스
Solid Relevance

[C++ 알고리즘] 백준 21609번 : 상어 중학교

Fri, 30 Apr 2021 00:00:00 +0000

Implementation BFS

상어 중학교

풀이과정

상어 초등학교 문제와 마찬가지로 우선순위 큐를 이용해 구현하였다.

크기가 가장 큰 블록 찾기(BFS)     -> find_block()
중력 적용                        -> down()
90도 반시계 방향 회전             -> rotate()
중력 적용                        -> down()

위의 문제 요구사항대로 차근차근 구현만 해주면 쉽게 끝난다.

여기서 헷갈릴만한 부분은 크게 두 가지가 있는 것 같다.

(1) BFS시 무지개 블록 방문 처리

가장 큰 블록을 찾을 때 방문하는 visit 배열에서 무지개 블록을 처리하면 안된다. 나는 새로운 블록 그룹을 만날때마다 bool rainbowVisit[20][20]라는 visit 배열을 새로 만들어주었다.

(2) 우선순위 큐 구현

나는 내 맘대로 info라는 구조체를 만들고 비교함수를 구현했다.

struct info {
	int x, y, cnt = 0, rainbowCnt = 0;
	bool operator<(const info& i) const {
		if (cnt == i.cnt) {
			if (rainbowCnt == i.rainbowCnt) {
				if (x == i.x) return y < i.y;
				else return x < i.x;
			}
			else return rainbowCnt < i.rainbowCnt;
		}
		else return cnt < i.cnt;
	}
};

근데 상어 초등학교 문제도 그렇고 이 문제도 그렇고 tuple<int,int,int,int>을 이용하는 사람이 많더라. tuple은 두 가지의 변수만 저장할 수 있는 pair와 달리 저장할 수 있는 변수에 제한이 없다고 한다. 비교함수도 구현되어있어서 상어중학교같이 비교함수가 간단한 문제의 경우 적극 활용하면 좋을것 같다!

크기가 가장 큰 블록
무지개 개수가 많은 블록
행이 큰 블록
열이 큰 블록

현재 문제 조건에서는 pQ.push({cnt, rainbowCnt, x, y})로 해주면 되고, 여기서 만약 3번 조건이 행이 작은 블록이라면 pQ.push({cnt, rainbowCnt, -x, y}) 이런식으로 작성해서 사용하면 유용할 것 같다.

코드

#include <iostream>
#include <vector>
#include <algorithm>
#include <queue>

using namespace std;

#define x first
#define y second
#define BLANK -2

struct info {
	int x, y, cnt = 0, rainbowCnt = 0;
	bool operator<(const info& i) const {
		if (cnt == i.cnt) {
			if (rainbowCnt == i.rainbowCnt) {
				if (x == i.x) return y < i.y;
				else return x < i.x;
			}
			else return rainbowCnt < i.rainbowCnt;
		}
		else return cnt < i.cnt;
	}
};

int res = 0;
int N, M;
int board[20][20];

int dx[4] = { 0,0,-1,1 };
int dy[4] = { -1,1,0,0 };

void input();
bool find_block();	//블록 찾기
void down();		//중력 작용
void rotate();		//반시계 회전

int main() {
	cin.tie(NULL); cout.tie(NULL); ios_base::sync_with_stdio(false);

	input();
	while (true) {
		int ret = find_block();
		if (!ret) break;			//블록이 없는 경우 종료
		down();
		rotate();
		down();
	}
	cout << res << '\n';

	return 0;
}

void input() {
	//freopen("input.txt", "r", stdin);

	cin >> N >> M;
	for (int i = 0; i < N; i++) {
		for (int j = 0; j < N; j++) {
			cin >> board[i][j];
		}
	}
}

bool find_block() {
	bool visit[20][20] = { false, };
	priority_queue<info> pQ;

	// 블록을 찾아 priority queue에 삽입
	for (int i = 0; i < N; i++) {
		for (int j = 0; j < N; j++) {
			if (board[i][j] > 0 && !visit[i][j]) {
				bool rainbowVisit[20][20] = { false, };
				queue<pair<int,int>> Q;
				Q.push({ i,j });
				visit[i][j] = true;

				int cnt = 1, rainbowCnt = 0;
				while (!Q.empty()) {
					int x = Q.front().x;
					int y = Q.front().y;
					Q.pop();

					for (int d = 0; d < 4; d++) {
						int nx = x + dx[d];
						int ny = y + dy[d];

						if (nx<0 || nx>N - 1 || ny<0 || ny>N - 1
							|| visit[nx][ny] || rainbowVisit[nx][ny]) continue;

						if (board[nx][ny] == 0) {
							rainbowVisit[nx][ny] = true;
							Q.push({ nx,ny });
							cnt++;
							rainbowCnt++;
						}
						else if (board[i][j] == board[nx][ny]) {
							visit[nx][ny] = true;
							Q.push({ nx,ny });
							cnt++;
						}
					}
				}

				pQ.push({ i,j,cnt, rainbowCnt });
			}
		}
	}

  // 더 이상 삭제할 블록이 없는 경우 false를 반환하고 main 함수 종료
	if (pQ.empty()) return false;

	// 가장 큰 블록 찾기
	int x = pQ.top().x;
	int y = pQ.top().y;
	int cnt = pQ.top().cnt;

	if (cnt < 2) return false;

	res += cnt * cnt;

	// 블록 삭제 작업 -> 삭제된 블록에는 BLANK(-2) 넣기
	queue<pair<int, int>> Q;
	Q.push({x,y });
	int blockId = board[x][y];
	board[x][y] = BLANK;

	while (!Q.empty()) {
		int x = Q.front().x;
		int y = Q.front().y;
		Q.pop();

		for (int d = 0; d < 4; d++) {
			int nx = x + dx[d];
			int ny = y + dy[d];

			if (nx<0 || nx>N - 1 || ny<0 || ny>N - 1) continue;

			if (board[nx][ny] == 0 ||  board[nx][ny]== blockId) {
				Q.push({ nx,ny });
				board[nx][ny] = BLANK;
			}
		}
	}

	return true;
}

void down() {
	for (int i = 0; i < N; i++) {
		for (int j = N - 1; j >= 0;j--) {
			if (board[j][i] == BLANK) {
				int x = j;
				int y = i;
				while (x > 0 && board[x][y]==BLANK) x--;
				if (board[x][y] == -1) continue;
				board[j][i] = board[x][y];
				board[x][y] = BLANK;
			}
		}
	}
}

void rotate() {
	int tempBoard[20][20];
	for (int i = 0; i < N; i++) {
		for (int j = 0; j < N; j++) {
			tempBoard[i][j] = board[i][j];
		}
	}
	for (int i = 0; i < N; i++) {
		for (int j = 0; j < N; j++) {
			board[i][j] = tempBoard[j][N-1-i];
		}
	}
}

결과

[C++ 알고리즘] 백준 21608번 : 상어 초등학교

Thu, 29 Apr 2021 00:00:00 +0000

Implementation

상어 초등학교

풀이과정

우선순위큐를 이용해서 구현하였다.

순서대로 학생의 자리 정하기
만족도 구하기 를 구현만 해주면 끝난다!

가장 핵심적인 부분은 우선순위큐를 작성하는 부분인 것 같다.

비어있는 칸 중에서 좋아하는 학생이 인접한 칸에 가장 많은 칸으로 자리를 정한다.
1을 만족하는 칸이 여러 개이면, 인접한 칸 중에서 비어있는 칸이 가장 많은 칸으로 자리를 정한다.
2를 만족하는 칸도 여러 개인 경우에는 행의 번호가 가장 작은 칸으로, 그러한 칸도 여러 개이면 열의 번호가 가장 작은 칸으로 자리를 정한다.

위의 요구대로 아래와 같이 코드를 작성했다.

// blankCnt : 비어있는 칸의 개수
// friendCnt : 인접한 칸에 있는 좋아하는 학생의 수
struct info {
	int x, y, blankCnt=0, friendCnt = 0;
	bool operator <(const info& i) const {
		if (friendCnt == i.friendCnt) {
			if (blankCnt == i.blankCnt) {
				if (x == i.x) return y > i.y;
				else return x > i.x;
			}
			else return blankCnt < i.blankCnt;
		}
		else return friendCnt < i.friendCnt;
	}
};

로 비교함수를 만들었고, 전체 자리를 우선순위큐priority_queue<info> pQ에 넣어 준 후 우선순위 큐의 top에 있는 자리에 학생을 배치해주면 끝이다.

코드

#include <iostream>
#include <vector>
#include <algorithm>
#include <queue>

using namespace std;

struct info {
	int x, y, blankCnt=0, friendCnt = 0;
	bool operator <(const info& i) const {
		if (friendCnt == i.friendCnt) {
			if (blankCnt == i.blankCnt) {
				if (x == i.x) return y > i.y;
				else return x > i.x;
			}
			else return blankCnt < i.blankCnt;
		}
		else return friendCnt < i.friendCnt;
	}
};

struct student {
	int id;
	int love[4];
	int x, y;
};

int manjok[] = { 0,1,10,100,1000 };

int dx[4] = { 0,0,-1,1 };
int dy[4] = { -1,1,0,0 };

int main() {
	cin.tie(NULL); cout.tie(NULL); ios_base::sync_with_stdio(false);

	// 0. 입력
	int N;
	int board[20][20] = {0,};

	cin >> N;

	vector<student> students(N * N);
	for (int i = 0; i < N * N; i++) {
		cin >> students[i].id;
		for (int j = 0; j < 4; j++) {
			cin >> students[i].love[j];
		}
	}

	// 1. 자리 배치하기
	for (int s = 0; s < N * N; s++) {
		priority_queue<info> pQ;

		for (int i = 0; i < N; i++) {
			for (int j = 0; j < N; j++) {
				if (board[i][j] == 0) {
					int blankCnt = 0, friendCnt = 0;
					for (int d = 0; d < 4; d++) {
						int nx = i + dx[d];
						int ny = j + dy[d];

						if (nx<0 || nx>N - 1 || ny<0 || ny>N - 1) continue;
						if (board[nx][ny] == 0) blankCnt++;
						else {
							for (int k = 0; k < 4; k++) {
								if (board[nx][ny] == students[s].love[k]) {
									friendCnt++;
									break;
								}
							}
						}
					}
					pQ.push({ i,j,blankCnt , friendCnt });
				}
			}
		}

		if (!pQ.empty()) {
			int x = pQ.top().x;
			int y = pQ.top().y;

			board[x][y] = students[s].id;
			students[s].x = x;
			students[s].y = y;
		}
	}

	// 2. 만족도 계산
	int res = 0;
	for (int s = 0; s < N * N; s++) {
		int x = students[s].x;
		int y = students[s].y;

		int friends = 0;
		for (int d = 0; d < 4; d++) {
			int nx = x + dx[d];
			int ny = y + dy[d];

			if (nx<0 || nx>N - 1 || ny<0 || ny>N - 1) continue;
			for (int k = 0; k < 4; k++) {
				if (board[nx][ny] == students[s].love[k]) {
					friends++;
					break;
				}
			}
		}
		res += manjok[friends];
	}

	cout << res;

	return 0;
}

결과

[C++ 알고리즘] 백준 10942번 : 팰린드롬?

Wed, 07 Apr 2021 00:00:00 +0000

DP

팰린드롬?

풀이과정

1. 알고리즘 선택

문제를 보자마자 떠올렸던 풀이방법의 시간복잡도를 계산해보았다.

s,e를 입력받을 때 마다 s~e까지 검사하며 팰린드롬 여부를 확인하는 방법

이 방법은 1 ≤ N ≤ 2,000 이고, 1 ≤ M ≤ 1,000,000 이므로 최악의 경우 2,000* 1,000,000 = 2,000,000,000 (20억번)의 연산 횟수가 발생한다.

따라서 시간복잡도를 줄일 수 있는 방법이 필요했고, 일단 DP 같은데 조건을 어떻게 세워야할 지 몰라서 테스트케이스를 보면서 규칙을 찾았다.

2. 규칙 찾기

palindrom[s][e] = s~e 까지 수의 팰린드롬 여부

테스트케이스	1	2	1	3	1	2	1
palindrom	[1]	[2]	[3]	[4]	[5]	[6]	[7]
[1]	o	x	o	x	x	x	o
[2]		o	x	x	x	o	x
[3]			o	x	o	x	x
[4]				o	x	x	x
[5]					o	x	o
[6]						o	x
[7]							o

s ~ e까지가 팰린드롬이려면 s+1 ~ e-1 까지도 팰린드롬이어야 한다. 이 조건은 arr[s] == arr[e] && palindrom[s + 1][e - 1] == true로 표현할 수 있다.

따라서 palindrom[i][i]일때를 초기화 해주고,

for (int i = 1; i <= n; i++) {
	palindrom[i][i] = true;
}

(s, e)에서 palindrom[s + 1][e - 1]의 값에 접근하기 위해 반복문을 거꾸로 돌렸다.

for (int i = n - 1; i >= 1; i--) {
	for (int j = i + 1; j <= n; j++) {
	}
}

3. 예외 상황

코드를 작성했는데, 위의 테스트케이스일 때 오답을 출력해서 확인해보니, palindrom[i][i]일때 뿐만 아니라 palindrom[i][i+1] 또한 초기화해줘야함을 알았다.

for (int i = 1; i <= n - 1; i++) {
	if (arr[i] == arr[i + 1])
		palindrom[i][i + 1] = true;
}

를 추가하고

for (int i = n - 1; i >= 1; i--) {
	for (int j = i + 2; j <= n; j++) {
	}
}

로 반복문을 수정했다.

코드

#include <iostream>
#include <vector>
#include <queue>
#include <algorithm>

using namespace std;

int arr[2001];
bool palindrom[2001][2001] = { false, };

int main()
{
	cin.tie(NULL); cout.tie(NULL); ios_base::sync_with_stdio(false);

	int n;
	cin >> n;

	for (int i = 1; i <= n; i++) {
		cin >> arr[i];
	}

	for (int i = 1; i <= n - 1; i++) {
		if (arr[i] == arr[i + 1])
			palindrom[i][i + 1] = true;
	}

	for (int i = 1; i <= n; i++) {
		palindrom[i][i] = true;
	}

	for (int i = n - 1; i >= 1; i--) {
		for (int j = i + 2; j <= n; j++) {
			if (arr[i] == arr[j] && palindrom[i + 1][j - 1] == true) {
				palindrom[i][j] = true;
			}
		}
	}

	int m, s, e;
	cin >> m;

	for (int i = 0; i < m; i++) {
		cin >> s >> e;
		cout << palindrom[s][e] << '\n';
	}

	return 0;
}

[C++ 알고리즘] 2021 KAKAO : 합승 택시 요금

Thu, 18 Mar 2021 00:00:00 +0000

Dijkstra Floyd–Warshall

합승 택시 요금

풀이과정

백준의 특정한 최단 경로 문제와 비슷하다고 느꼈다.

다익스트라랑 플로이드-와샬 두 가지 방법으로 풀어보았는데, 플로이드-와샬이 더 효율이 좋았다. 모든 정점에서 모든 정점까지의 최단 거리를 구할 때는 플로이드-와샬, 한 정점에서 다른 정점까지의 최단 거리를 구할 때는 다익스트라를 사용하는 것이 맞는 것 같다.

복잡도	다익스트라	플로이드-와샬
시간복잡도	인접행렬 : \(O(V^2)\) 인접리스트 + 우선순위 큐 : \(O(E log V) + O(E)\)	\(O(V^3)\)
공간복잡도	인접행렬 : \(O(V^2)\) 인접리스트 : \(O(V) + O(E)\)	\(O(V^2)\)

(1) 정점 간 최단 경로를 모두 구해야 하는 경우

간선이 많음 -> 플로이드-와샬
간선이 적음 -> 플로이드-와샬(\(O(V^3)\)), 다익스트라 (\(O(E log V) + O(E)\))

(2) 한 정점에서 다른 정점까지의 최단 경로만 구해야 하는 경우

간선이 많음 -> 인접행렬 + 다익스트라
간선이 적음 -> 인접리스트 + 다익스트라

코드

궁금해서 두 가지 방법으로 모두 풀어보았다.

다익스트라(우선순위 큐)

#include <string>
#include <vector>
#include <queue>

#define MAX 100'000'000

using namespace std;

void dijkstra(vector<pair<int,int>>* edges, vector<int>& dist, int start) {
    priority_queue<pair<int,int>> pQ;
    pQ.push({0, start});
    dist[start] = 0;

    int v,w;
    while(!pQ.empty()){
        w = pQ.top().first;
        v = pQ.top().second;
        pQ.pop();

        if(dist[v] < -w) continue;

        for(auto it = edges[v].begin(); it!=edges[v].end();it++){
            if(dist[it->first] > dist[v] + it->second){
                dist[it->first] = dist[v] + it->second;
                pQ.push({-dist[it->first],it->first});
            }
        }
    }
}

int solution(int n, int s, int a, int b, vector<vector<int>> fares) {
    vector<pair<int,int>> edges[201];
    for(int i=0;i<fares.size();i++){
        edges[fares[i][0]].push_back({fares[i][1],fares[i][2]});
        edges[fares[i][1]].push_back({fares[i][0],fares[i][2]});
    }

    vector<vector<int>> dist(n+1, vector<int>(n+1, MAX));

    for(int i=1;i<=n;i++){
        dijkstra(edges, dist[i], i);
    }

    int answer = MAX;
    for(int i=1;i<=n;i++){
        if(answer> dist[s][i] + dist[i][a]+ dist[i][b]){
            answer= dist[s][i] + dist[i][a]+ dist[i][b];
        }
    }

    return answer;
}

플로이드-와샬

#include <string>
#include <vector>
#include <queue>
#include <algorithm>

#define MAX 100'000'000

using namespace std;

int solution(int n, int s, int a, int b, vector<vector<int>> fares) {
    vector<vector<int>> dist(n+1, vector<int>(n+1, MAX));

    for(int i=0;i<fares.size();i++){
        dist[fares[i][0]][fares[i][1]] = fares[i][2];
        dist[fares[i][1]][fares[i][0]] = fares[i][2];
    }

    for(int i=1;i<=n;i++) dist[i][i] = 0;

    for (int k = 1; k <= n; k++) {
		for (int i = 1; i <= n; i++) {
			for (int j = 1; j <= n; j++) {
				dist[i][j] = min(dist[i][j], dist[i][k] + dist[k][j]);
			}
		}
	}

    int answer = MAX;
    for (int i = 1; i <= n; i++) {
            answer = min(answer, dist[s][i] + dist[i][a]+dist[i][b]);
    }

    return answer;
}

결과

다익스트라

테스트 1 〉통과 (1.76ms, 3.97MB)
테스트 2 〉통과 (6.56ms, 4.15MB)
테스트 3 〉통과 (3.69ms, 3.98MB)
테스트 4 〉통과 (3.57ms, 3.97MB)
테스트 5 〉통과 (3.57ms, 3.93MB)
테스트 6 〉통과 (3.66ms, 3.96MB)
테스트 7 〉통과 (27.65ms, 8.13MB)
테스트 8 〉통과 (27.16ms, 7.99MB)
테스트 9 〉통과 (14.34ms, 8.09MB)
테스트 10 〉통과 (14.45ms, 8.05MB)
테스트 11 〉통과 (14.35ms, 8.09MB)
테스트 12 〉통과 (19.59ms, 5.83MB)
테스트 13 〉통과 (19.34ms, 5.83MB)
테스트 14 〉통과 (19.48ms, 5.79MB)
테스트 15 〉통과 (19.33ms, 5.77MB)
테스트 16 〉통과 (3.22ms, 3.92MB)
테스트 17 〉통과 (3.17ms, 3.96MB)
테스트 18 〉통과 (3.27ms, 3.97MB)
테스트 19 〉통과 (7.11ms, 3.98MB)
테스트 20 〉통과 (9.79ms, 4.28MB)
테스트 21 〉통과 (9.92ms, 4.27MB)
테스트 22 〉통과 (19.35ms, 5.73MB)
테스트 23 〉통과 (19.09ms, 5.68MB)
테스트 24 〉통과 (19.36ms, 5.75MB)
테스트 25 〉통과 (2.08ms, 3.98MB)
테스트 26 〉통과 (1.64ms, 3.95MB)
테스트 27 〉통과 (10.75ms, 4.16MB)
테스트 28 〉통과 (11.08ms, 4.09MB)
테스트 29 〉통과 (1.23ms, 3.77MB)
테스트 30 〉통과 (1.23ms, 3.9MB)

플로이드-와샬

테스트 1 〉통과 (0.81ms, 3.96MB)
테스트 2 〉통과 (2.66ms, 4.07MB)
테스트 3 〉통과 (5.72ms, 3.82MB)
테스트 4 〉통과 (5.76ms, 3.95MB)
테스트 5 〉통과 (5.73ms, 3.93MB)
테스트 6 〉통과 (5.73ms, 3.96MB)
테스트 7 〉통과 (6.72ms, 7.65MB)
테스트 8 〉통과 (7.02ms, 7.56MB)
테스트 9 〉통과 (6.93ms, 7.59MB)
테스트 10 〉통과 (6.95ms, 7.61MB)
테스트 11 〉통과 (6.89ms, 7.56MB)
테스트 12 〉통과 (6.26ms, 5.54MB)
테스트 13 〉통과 (6.28ms, 5.51MB)
테스트 14 〉통과 (6.28ms, 5.61MB)
테스트 15 〉통과 (6.37ms, 5.44MB)
테스트 16 〉통과 (5.77ms, 3.97MB)
테스트 17 〉통과 (5.74ms, 3.96MB)
테스트 18 〉통과 (5.76ms, 3.96MB)
테스트 19 〉통과 (5.79ms, 3.94MB)
테스트 20 〉통과 (5.88ms, 4.16MB)
테스트 21 〉통과 (5.88ms, 4.14MB)
테스트 22 〉통과 (6.32ms, 5.61MB)
테스트 23 〉통과 (6.31ms, 5.54MB)
테스트 24 〉통과 (6.31ms, 5.56MB)
테스트 25 〉통과 (5.75ms, 3.97MB)
테스트 26 〉통과 (5.73ms, 3.96MB)
테스트 27 〉통과 (5.87ms, 4.02MB)
테스트 28 〉통과 (5.85ms, 4.1MB)
테스트 29 〉통과 (0.78ms, 3.95MB)
테스트 30 〉통과 (0.78ms, 3.95MB)

:bookmark: REFERENCE
플로이드, 다익스트라 알고리즘 비교
다익스트라 알고리즘(Dijkstra)

[C++ 알고리즘] 프로그래머스 : 조이 스틱

Fri, 12 Mar 2021 00:00:00 +0000

Greedy

조이 스틱

풀이과정

알파벳 위 아래로 조작하는 건 알겠고, 단순히 오른쪽으로 쭉 이동하거나 왼쪽에서 쭉 이동하는 것만 비교해서 제출했더니 11번 테케에서 오류나서 구글링의 힘을 빌렸다..

간단한 건데도 이해하기 힘들어서 직접 써서 증명하면서 풀었다 ㅠㅠ 그리디 넘 어려웡

name[i]에서 가장 가까운 A가 아닌 문자 name[ind] 찾기
여기서 조이스틱을 움직이는 최단 경로는
(1) 원점 –> i –> 원점 –> ind
(2) 원점 –> ind –> 원점 –> i
이렇게 두 가지이다.
따라서 (i : 0~name.length)에 대해 조이스틱을 움직이는 최소값을 구한다.

반례인 “ABABAAAAABA”에 대해 위 풀이를 수식으로 설명해보면 다음과같다.

코드

#include <algorithm>
#include <string>

using namespace std;

int solution(string name) {
    int answer = 0;
    int n = name.length();
    int turn = n - 1; //조이스틱을 한 방향으로 쭉 움직였을 때
    for (int i = 0; i < n; i++) {
        if (name[i] - 'A' < 14) answer += name[i] - 'A';
        else answer += 'Z' - name[i] + 1;

        int ind = i + 1;
        while (ind < n && name[ind] == 'A') ind++;

        turn = min(turn, i + n - ind + min(i, n - ind));
    }

    answer += turn;
    return answer;
}

:bookmark: REFERENCE
[프로그래머스] 조이스틱

[Design Pattern] MVC, MVP, MVVM 패턴이란?

Mon, 08 Mar 2021 00:00:00 +0000

MVC(Model-View-Controller)

구성요소

Model : 프로그램에서 사용되는 데이터, 데이터를 처리하는 로직을 담당
View : 사용자가 보는 부분, 데이터가 보여지는 UI
Controller : 사용자의 입력을 받고 처리

구조

동작 방식

사용자의 입력이 Controller에 들어옴
Controller는 사용자의 입력을 확인한 후 Model을 업데이트함
Model은 보여줄 View 선택
View는 변경된 Model을 이용해 사용자에게 보여줄 UI 업데이트

특징

Controller와 View는 1:N 관계를 가진다.

장점

보편적이며, 단순한 구조이므로 구현하기 쉽다.

단점

Model과 View 사이의 의존성이 높다.

MVP(Model-View-Presenter)

구성요소

Model : 프로그램에서 사용되는 데이터, 데이터를 처리하는 로직을 담당
View : 사용자가 보는 부분, 데이터가 보여지는 UI, 사용자의 입력을 받음
Presenter : View에서 요청한 대로 Model을 가공해 View에 전달

구조

동작 방식

사용자의 입력 View에 들어옴
View는 사용자의 입력을 확인한 후 Presenter에 요청함
Presenter는 Model에 데이터를 요청함
Model은 Presenter에 데이터를 응답함
Presenter는 Model로부터 응답받은 데이터를 View에 응답함
View는 사용자에게 보여줄 UI 업데이트

특징

Presenter와 View는 1:1 관계를 가진다.
Model과 View는 독립적이다.

장점

MVC의 단점이었던 Model과 View 사이의 의존성이 없다.

단점

Model과 View 사이의 의존성은 없지만, View와 Presenter 사이 의존성이 생긴다.

MVVM(Model-View-ViewModel)

구성요소

Model : 프로그램에서 사용되는 데이터, 데이터를 처리하는 로직을 담당
View : 사용자가 보는 부분, 데이터가 보여지는 UI, 사용자의 입력을 받음
ViewModel : View를 나타내기위한 데이터를 처리하는 View를 위한 Model

구조

동작 방식

사용자의 입력이 View에 들어옴
View는 사용자의 입력을 확인한 후 ViewModel에 입력을 전달함
ViewModel은 Model에 데이터를 요청함
Model은 ViewModel에 데이터를 응답함
ViewModel은 데이터를 View를 위한 데이터를 가공하고 저장함
View는 ViewModel에 저장된 데이터를 이용해 UI 업데이트

특징

ViewModel과 View는 1:N 관계를 가진다.
MVVM에서는 커맨드 패턴과 데이터바인딩을 사용한다.
- 커맨드 패턴 : View에 입력이 들어오면 커맨드 패턴으로 ViewModel에 명령
- 데이터바인딩 : ViewModel의 값이 변하면 자동으로 UI가 업데이트됨

장점

Model과 View 사이에 의존성이 없다.
View와 ViewModel 사이에 의존성이 없다.
각 부분이 독립적이므로 모듈화하여 개발할 수 있다.

단점

구현 및 설계가 어렵다.

:bookmark: REFERENCE
[디자인패턴] MVC, MVP, MVVM 비교
MVC, MVP, MVVM 비교

[C++ 알고리즘] 백준 1865번 : 웜홀

Thu, 04 Mar 2021 00:00:00 +0000

벨만포드

웜홀

풀이과정

벨만-포드 알고리즘을 이용해 해결하였다.

시간이 줄어들면서 출발 위치로 돌아오는 것 을 보고 벨만포드를 떠올리기
도로는 무방향이므로 양방향 간선 2개를 추가하기
웜홀의 가중치는 음수로 취급하기

이 세가지는 캐치했지만 놓친 부분이 있었다.

(1) 모든 정점에서 음의 사이클의 여부를 판단하였다.

vector<vector<int>> dist(n + 1, vector<int>(n + 1, MAX));
for (int k = 1; k <= n; k++) {
  dist[k][k] = 0;
  ...
}

대략 이런식으로 했더니 시간초과가 났고, 음의 사이클 여부는 임의의 한 정점에서 시작해도 판단할 수 있음을 깨달았다. 그래서 출발점이 무조건 1이라는 건가요 어떤 노드든 상관 없다는 건가요? 글을 읽어보면 된다.

(2) dist[s]==MAX 인 경우 지나치기

if (dist[s] != MAX && dist[e] > dist[s] + t) {
  dist[e] = dist[s] + t;
}

기존에 벨만포드를 풀 때 위와 같이 풀었어서 이번에도 저렇게 풀었으나, 자꾸 9%에서 틀렸습니다가 떠서 확인해보니 저 부분에서 문제가 있다는 것을 알았다. INF비교가 없어야 하는 이유가 뭘까요? 이 질문이 도움이 많이 되었다!

다음은 반례이다

1
2 0 1
2 2 1

정답 : YES

INF 비교를 추가하면 위 반례에서 NO가 뜰 것이다.

코드

#include <iostream>
#include <string>
#include <vector>

#define MAX 30'000'000

using namespace std;

int n, m, w;

struct edge {
	int s, e, t;
};

bool time_travel(int n, vector<edge> edges) {
	vector<int> dist(n + 1, MAX);

	int s, e, t;
	dist[1] = 0;
	for (int i = 1; i < n; i++) {
		for (int j = 0; j < edges.size(); j++) {
			s = edges[j].s;
			e = edges[j].e;
			t = edges[j].t;
			if (dist[e] > dist[s] + t) {
				dist[e] = dist[s] + t;
			}
		}
	}
	for (int j = 0; j < edges.size(); j++) {
		s = edges[j].s;
		e = edges[j].e;
		t = edges[j].t;
		if (dist[e] > dist[s] + t) {
			return true;
		}
	}

	return false;
}

int main()
{
	cin.tie(NULL); cout.tie(NULL); ios_base::sync_with_stdio(false);

	int TC;
	cin >> TC;

	int s, e, t;
	while (TC > 0) {
		cin >> n >> m >> w;

		vector<edge> edges;

		for (int i = 0; i < m; i++) {
			cin >> s >> e >> t;
			edges.push_back({ s,e,t });
			edges.push_back({ e,s,t });
		}
		for (int i = 0; i < w; i++) {
			cin >> s >> e >> t;
			edges.push_back({ s,e,-t });
		}

		if (time_travel(n, edges)) cout << "YES\n";
		else cout << "NO\n";

		TC--;
	}

	return 0;
}

:bookmark: REFERENCE
그래서 출발점이 무조건 1이라는 건가요 어떤 노드든 상관 없다는 건가요?
INF비교가 없어야 하는 이유가 뭘까요?

[C++ 알고리즘] 2021 KAKAO : 메뉴 리뉴얼

Tue, 02 Mar 2021 00:00:00 +0000

DFS Brute Force

메뉴 리뉴얼

풀이과정

내가 수행한 전체 Process는 다음과 같다.

메뉴 조합 구하기
요리 n개의 코스 중 가장 많이 주문된 것들 구하기
answer에 추가 후 정렬

1번은 손님들이 주문한 전체 메뉴들 중 DFS를 이용해 nCm의 조합을 구했다. 코스(조합)를 구한 후에는 각 코스가 손님들에게서 주문된 적 있는지 검사 후 최댓값을 추출하였다. 풀면서 BOJ 복면산 문제가 생각이 나서 비슷하게 풀었는데, 다른 풀이를 보니 나는 너무 복잡하게 푼 것 같다 ㅠㅅㅠ.. map을 이용해서 풀 수도 있고 전역변수를 쓸데없이 많이 선언하지 않고 매개변수에 string을 넣어서 푸는 방법도 있었다. 다음엔 더 깔끔하게 풀 수 있도록 노력해야지😭

코드

#include <string>
#include <vector>
#include <iostream>
#include <algorithm>

using namespace std;

bool isAlphabetExist[26] = {false,};
vector<char> alphabetArray;
vector<bool> isAlphabetChecked;
char selectedCourse[11];
vector<string> tempAnswer;
int tempMax = 0;

int counting_menu(vector<string> orders, int limit) {
	int cnt = 0;
	for (int i = 0; i < orders.size(); i++) {
		int j;
		for (j = 0; j < limit; j++) {
			if (orders[i].find(selectedCourse[j]) == string::npos) break;
		}
		//조합 있는경우
		if (j == limit) cnt++;
	}
	return cnt;
}

void dfs(vector<string> orders, int level, int pos, int limit) {
	if (level == limit) {
		// 각 조합에 대해 몇번 나왔는지 세기
		int res = counting_menu(orders, limit);
		if (tempMax <= res) {
			if (tempMax < res) {
				tempMax = res;
				tempAnswer.clear();
			}
			string combination = "";
			for (int i = 0; i < level; i++)
				combination += selectedCourse[i];
			tempAnswer.push_back(combination);
		}
	}
	else {
		for (int i = pos; i < isAlphabetChecked.size(); i++) {
			if (!isAlphabetChecked[i]) {
				isAlphabetChecked[i] = true;
				selectedCourse[level] = alphabetArray[i];
				dfs(orders, level+1, i+1, limit);
				isAlphabetChecked[i] = false;
			}
		}
	}
}

vector<string> solution(vector<string> orders, vector<int> course) {
    vector<string> answer;

	// 1. 출현한 알파벳 구하기
	for (int i = 0; i < orders.size(); i++) {
		for (int j = 0; j < orders[i].size(); j++) {
			int ind = orders[i][j] - 'A';
			isAlphabetExist[ind] = true;
		}
	}

	// 2. 존재하는 알파벳만 추출하기
	for (int i = 0; i < 26; i++) {
		if (isAlphabetExist[i]) {
			alphabetArray.push_back(i + 'A');
			isAlphabetChecked.push_back(false);
		}
	}

	// 3. 각 n개의 코스에 대해 solution
	for (int i = 0; i < course.size(); i++) {
		for (int j = 0; j < isAlphabetChecked.size(); j++) {
			isAlphabetChecked[j] = false;
		}

		// 4. 조합 구하기
		tempAnswer.clear();
		tempMax = 2;
		dfs(orders, 0, 0, course[i]);

		for (int j = 0; j < tempAnswer.size(); j++) {
			answer.push_back(tempAnswer[j]);
		}
	}

  // 5. 정렬
	sort(answer.begin(), answer.end());

    return answer;
}

결과

테스트 1 〉	통과 (0.18ms, 3.91MB)
테스트 2 〉	통과 (0.12ms, 3.95MB)
테스트 3 〉	통과 (0.06ms, 3.91MB)
테스트 4 〉	통과 (0.12ms, 3.94MB)
테스트 5 〉	통과 (0.14ms, 3.94MB)
테스트 6 〉	통과 (0.23ms, 3.94MB)
테스트 7 〉	통과 (0.23ms, 3.92MB)
테스트 8 〉	통과 (0.97ms, 3.93MB)
테스트 9 〉	통과 (2.65ms, 3.94MB)
테스트 10 〉	통과 (41.07ms, 3.94MB)
테스트 11 〉	통과 (26.88ms, 3.97MB)
테스트 12 〉	통과 (39.37ms, 3.93MB)
테스트 13 〉	통과 (4096.20ms, 3.96MB)
테스트 14 〉	통과 (5098.76ms, 3.93MB)
테스트 15 〉	통과 (2043.62ms, 3.98MB)
테스트 16 〉	통과 (1.91ms, 3.94MB)
테스트 17 〉	통과 (19.09ms, 3.94MB)
테스트 18 〉	통과 (13.00ms, 3.72MB)
테스트 19 〉	통과 (0.80ms, 3.94MB)
테스트 20 〉	통과 (2.76ms, 3.94MB)

:bookmark: REFERENCE
[프로그래머스] 메뉴 리뉴얼 문제 풀이 (2021 카카오 코딩테스트)

[C++ 알고리즘] 백준 1238번 : 파티

Mon, 15 Feb 2021 00:00:00 +0000

파티

풀이과정

다익스트라 알고리즘을 이용해 문제를 해결하였다. 이 문제를 풀기 전에 같은 다익스트라 문제인 1753번, 1916번 문제를 먼저 풀어보는게 좋다.

다익스트라 알고리즘
간선의 가중치가 모두 양수일 때 사용하는 알고리즘이다. 항상 최소 비용을 비교하여 갱신한다. 최단 거리가 정해진 노드는 더 이상 방문하지 않는다.

간선(도로)의 정보를 저장한다.
x 도시에서 y 도시로의 최단 거리를 저장할 이차원 배열 dist를 생성하고 기본값을 INT의 최대값으로 설정한다. dist[x][y] 는 x에서 y로의 최단 거리이다.
각 도시에 대해 다익스트라를 수행한다. 우선순위 큐(최소힙)를 이용해 가중치(시간)가 가장 작은 것을 고른다.
x도시에 사는 학생이 k도시를 왕복하는 최단거리는 dist[x][k] + dist[k][x]이다.
dist[x][k] + dist[k][x] 중 최대값을 찾는다.

코드

#include <iostream>
#include <limits.h>
#include <vector>
#include <queue>
#include <stack>

using namespace std;

struct edge {
    int end;
    int weight;
    edge(int a, int b) {
        end = a;
        weight = b;
    }
    bool operator<(const edge& e)const {
        return weight > e.weight;
    }
};

int main()
{
    cin.tie(NULL); cout.tie(NULL); ios_base::sync_with_stdio(false);

    int n, m, x;
    cin >> n >> m >> x;

    int s, e, w;
    vector<edge> graph[1001];
    for (int i = 0; i < m; i++) {
        cin >> s >> e >> w;
        graph[s].push_back(edge(e, w));
    }

    vector<vector<int> > dist(n + 1, vector<int>(n + 1, INT_MAX));
    for (int i = 1; i <= n; i++) {
        priority_queue<edge> pQ;
        pQ.push(edge(i, 0));
        dist[i][i] = 0;

        while (!pQ.empty()) {
            e = pQ.top().end;
            w = pQ.top().weight;
            pQ.pop();

            //최단 거리가 정해진 곳은 방문하지 않음
            if (w > dist[i][e]) continue;

            for (auto it = graph[e].begin(); it != graph[e].end(); it++) {
                int a, b;
                a = (*it).end;
                b = (*it).weight;

                if (dist[i][a] > dist[i][e] + b) {
                    dist[i][a] = dist[i][e] + b;
                    pQ.push(edge(a,dist[i][a]));
                }
            }
        }
    }

    int res = 0;
    for (int i = 1; i <= n; i++) {
        res = max(res, dist[x][i] + dist[i][x]);
    }
    cout << res;

    return 0;
}

[C++ 알고리즘] 백준 15811번 : 복면산?!

Fri, 05 Feb 2021 00:00:00 +0000

DFS

복면산?!

풀이과정

dfs를 이용한 순열 구하기와 비슷한 문제이다.
입력된 알파벳에 0~9까지의 숫자를 모두 할당한 후 복면산인지 확인해야하므로 재귀함수를 이용한 dfs로 문제를 해결하였다.

전체 과정은 다음과 같다.

입력된 문자열에 대해 알파벳을 골라낸다.
A~Z 까지의 알파벳 중 입력된 알파벳이면 alphabet 배열에 넣는다.
alphabet의 원소에 0~9까지의 숫자를 할당한다.
숫자를 모두 할당하면 할당한 숫자로 복면산을 만들 수 있는지 확인한다.
복면산을 만들 수 있으면 isBokMyunSan = true로 플래그 값을 바꿔준다.

코드

#include <stdio.h>
#include <vector>
#include <string>
#include <queue>

using namespace std;

char str[3][20]; // 입력 string 저장

int number[3];	// string을 숫자로 변환하여 저장할 공간
int numOfAlphabet[26] = {-1};	// 각 알파벳에 해당하는 숫자를 저장할 공간

bool isExistAlphabet[26] = { false };	// 입력 string의 알파벳들의 존재여부를 저장할 공간
bool isUsedNumber[10] = { false };		// 0~9까지의 숫자를 사용했는지 체크할 공간

bool isBokMyunSan = false;		

vector<int> alphabet;		// 존재하는 알파벳만 담은 공간

int getNumber(string str) {
	int result = 0;
	int ind;
	for (int i =0; i < str.size(); i++) {
		ind = str[i] - 'A';
		result = result * 10 + numOfAlphabet[ind];
	}
	return result;
}

void dfs(int level) {
	if (isBokMyunSan) return;
	if (level == alphabet.size()) {
		for (int i = 0; i < 3; i++) {
			number[i] = getNumber(str[i]);
		}
		if (number[0] + number[1] == number[2]) {
			isBokMyunSan = true;
		}
	}
	else {
		for (int i = 0; i < 10; i++) {
			// 1. 0~9 중 할당되지 않은 숫자를 알파벳에 할당
			if (!isUsedNumber[i]) {
				isUsedNumber[i] = true;
				numOfAlphabet[alphabet[level]] = i;
				// 2. 다음 알파벳으로 이동
				dfs(level + 1);
				// 3. 재귀가 끝난 후 돌아오면 사용했던 숫자 반납
				isUsedNumber[i] = false;
			}
		}
	}
}

int main() {
	// 1. 입력
	for (int i = 0;i < 3; i++) {
		scanf("%s", str[i]);
	}

	// 2. 입력된 알파벳만 구별
	int ind;
	for (int k = 0; k < 3; k++) {
		for (int i = 0; str[k][i] != '\0'; i++) {
			ind = str[k][i] - 'A';
			if (!isExistAlphabet[ind]) isExistAlphabet[ind] = true;
		}
	}

	// 3. 중복을 제거한 알파벳 리스트 -> alphabetList
	for (int i = 0; i < 26; i++) {
		if (isExistAlphabet[i])
			alphabet.push_back(i);
	}

	dfs(0);

	if (isBokMyunSan) printf("YES\n");
	else printf("NO\n");

	return 0;
}

[C++ 알고리즘] 백준 10026번 : 적록색약

Tue, 02 Feb 2021 00:00:00 +0000

DFS BFS

적록색약

풀이과정

방향을 나타내는 배열을 만들어 상하좌우를 탐색한다.
입력받은 그림정보를 가공하여 적록색약인 사람에 대해 탐색한다.
- 색깔이 G인 경우 R로 바꾸고 탐색
함수의 재귀를 이용해 DFS를 수행한다.

코드

#include <stdio.h>
#include <string.h>

using namespace std;

int n, cnt = 0;
char photo[100][100];
bool isVisited[100][100] = { false };

int dx[4] = { 0,0,-1,1 };
int dy[4] = { -1,1,0,0 };

void dfs(int x, int y) {
	isVisited[x][y] = true;
	for (int i = 0; i < 4; i++) {
		int nx = x + dx[i];
		int ny = y + dy[i];

		if (nx < 0 || nx >= n || ny < 0 || ny >= n) continue;
		if (!isVisited[nx][ny] && photo[x][y] == photo[nx][ny]) {
			dfs(nx, ny);
		}
	}
}

int main() {
	scanf("%d", &n);
	for (int i = 0; i < n; i++) {
		scanf("%s", photo[i]);
	}

	//적록색약이 아닌 사람
	for (int i = 0; i < n; i++) {
		for (int j = 0; j < n; j++) {
			if (!isVisited[i][j]) {
				dfs( i, j);
				cnt++;
			}
		}
	}
	printf("%d ", cnt);

	//적록색약인 사람
	for (int i = 0; i < n; i++) {
		for (int j = 0; j < n; j++) {
			if (photo[i][j] == 'G') photo[i][j] = 'R';
			else photo[i][j] = photo[i][j];
		}
	}
	memset(isVisited, false, sizeof(isVisited));

	cnt = 0;
	for (int i = 0; i < n; i++) {
		for (int j = 0; j < n; j++) {
			if (!isVisited[i][j]) {
				dfs(i, j);
				cnt++;
			}
		}
	}
	printf("%d", cnt);

	return 0;
}

[Design Pattern] GoF 구조 패턴 - 어댑터 패턴(Adapter Pattern)

Fri, 29 Jan 2021 00:00:00 +0000

어댑터 패턴(Adapter Pattern)

GoF 디자인 패턴 중 구조 패턴에 해당한다.
클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴이다. 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해준다.
안드로이드 개발 시 자주 보게 되는 패턴 중 하나이므로 개념 정리를 해보았다.

사용법

기존 클래스를 사용하고 싶은데 인터페이스가 맞지 않을 때
기존에 만들어 놓은 것을 재사용하고 싶은데 그것을 수정할 수 없을 때

구조

클래스 어댑터(Class Adapter)

Adaptee는 변환이 필요하다.
Adaptor가 Adaptee를 필요한 형태로 변환시켜주고 Client는 Adaptor를 통해 이를 사용한다.
자바의 상속을 이용한다.

객체 어댑터(Object Adapter)

객체 어댑터 패턴에서 Adapter는 Adaptee의 인스턴스를 가진다.
자바의 합성을 이용한다.

장점

관련성이 없는 인터페이스를 같이 사용할 수 있음
클래스 재사용성 증가

예제

클래스 다이어그램

패키지 구조

구현

USB B 타입을 C 타입으로 바꾸어주는 Adaptor를 구현한다. USB B 타입이 Adaptee가 된다.

package adaptee;

public class Usb {
    private String type;

    public Usb(String type) {
        this.type = type;
    }

    public String getType() {
        return type;
    }

    public void setType(String type) {
        this.type = type;
    }
}

package adaptee;

public class UsbTypeB {
    public Usb getBType() {
        return new Usb("B");
    }
}

Adaptor를 interface로 구현해놓고 이를 Class Adaptor, Object Adaptor로 각각 구현해보았다.

package adapter;

import adaptee.Usb;

public interface BtoCAdapter {
    public Usb getCType();
}

클래스 어댑터

package adapter;

import adaptee.Usb;
import adaptee.UsbTypeB;

public class BtoCClassAdapterImpl extends UsbTypeB implements BtoCAdapter{
    @Override
    public Usb getCType() {
        return convertType(getBType(), "C");
    }

    private Usb convertType(Usb usb, String type){
        usb.setType(type);
        return usb;
    }
}

객체 어댑터

package adapter;

import adaptee.Usb;
import adaptee.UsbTypeB;

public class BtoCObjectAdapterImpl implements BtoCAdapter {

    private UsbTypeB usbTypeB;

    public BtoCObjectAdapterImpl(UsbTypeB usbTypeB) {
        this.usbTypeB = usbTypeB;
    }

    @Override
    public Usb getCType() {
        return convertType(usbTypeB.getBType(), "C");
    }

    private Usb convertType(Usb usb, String type){
        usb.setType(type);
        return usb;
    }
}

import adaptee.UsbTypeB;
import adapter.BtoCAdapter;
import adapter.BtoCClassAdapterImpl;
import adapter.BtoCObjectAdapterImpl;

public class Client {
    public static void main(String[] args) {
        //Class Adapter
        BtoCAdapter classAdapter = new BtoCClassAdapterImpl();
        System.out.println("Current USB Type : "+classAdapter.getCType().getType());


        //Object Adapter
        UsbTypeB usbTypeB = new UsbTypeB();
        System.out.println("Current USB Type : "+usbTypeB.getBType().getType());

        BtoCAdapter objectAdapter = new BtoCObjectAdapterImpl(usbTypeB);
        System.out.println("Current USB Type : "+objectAdapter.getCType().getType());
    }
}

[실행 결과]
Current USB Type : C
Current USB Type : B
Current USB Type : C

소스 코드

전체 소스 코드

:bookmark: REFERENCE
에릭 감마 외 3명, 「GoF의 디자인 패턴」, 피어슨에듀케이션코리아
어댑터 패턴
[구조 패턴] 어댑터 패턴(Adapter Pattern) 이해 및 예제

[C++ 알고리즘] 44. 마구간 정하기

Thu, 28 Jan 2021 00:00:00 +0000

44. 마구간 정하기

인프런의 it 취업을 위한 알고리즘 문제풀이 (with C/C++) : 코딩테스트 대비 강의를 수강하여 공부한 내용을 기록한 포스트입니다. 문제는 공개하지 않습니다.

풀이과정

43번 문제와 마찬가지로 이분검색 문제이다. 이분검색 문제에서는 이분검색할 범위를 찾는 것이 중요한 것 같다.

이분검색할 최대 범위를 찾는다. 이 범위는 배열의 크기가 아니므로 프로그래머가 찾아야한다.
그 값이 조건에 타당한지 검사 후 계속 이분검색을 수행하여 답을 찾는다.
이 문제는 이분검색할 범위를 입력의 최대값으로 정해야 해서 먼저 sort()를 통해 오름차순으로 정렬해주었다. 1~(입력의최댓값)이라는 범위를 찾고 나니 값을 결정하는 것은 쉬웠다.

코드

#include <stdio.h>
#include <vector>
#include <algorithm>

using namespace std;

int main() {
	int n, m;
	scanf("%d %d", &n, &m);

	vector<int> arr(n);
	for (int i = 0; i < n; i++) {
		scanf("%d", &arr[i]);
	}
	sort(arr.begin(), arr.end());

	int left = 1, right = arr[n - 1] - arr[0], mid;
	int cnt, res = 0, pre = 0;

	while (left <= right) {
		mid = (left + right) / 2;

		cnt = 1;
		pre = 0;

		for (int i = 1; i < n; i++) {
			if (arr[i] - arr[pre] >= mid) {
				cnt++;
				pre = i;
			}
		}

		if (cnt >= m) {
			res = mid;
			left = mid + 1;
		}
		else {
			right = mid - 1;
		}
	}

	printf("%d", res);

	return 0;
}

:bookmark: REFERENCE
인프런 it 취업을 위한 알고리즘 문제풀이 (with C/C++) : 코딩테스트 대비

[C++ 알고리즘] 43. 뮤직비디오

Thu, 28 Jan 2021 00:00:00 +0000

43. 뮤직비디오

풀이과정

이분검색을 응용하는 문제이다. 처음 문제를 보고 DP나 Brute Force를 사용하는건가 싶어서 막막했는데 아니었다 ㅠㅠ
이분검색을 이용하는 결정 알고리즘이라고 한다.

주어진 입력 내에서 가능한 최대 녹화 길이를 찾는다. 1 ~ 1,000*10,000
이분검색을 통해 가능한 녹화 길이를 결정한다.

코드

#include <stdio.h>
#include <vector>

using namespace std;

int main() {
	int n, m;
	scanf("%d %d", &n, &m);

	vector<int> arr(n);
	int sum = 0;
	for (int i = 0; i < n; i++) {
		scanf("%d", &arr[i]);
		sum += arr[i];
	}

	int left = 1, right = sum, mid;
	int partial_sum, min=sum, partial_cnt;


	while (left <= right) {
		mid = (left + right) / 2;
		partial_sum = 0;
		partial_cnt = 1;

		for (int i = 0; i < n; i++) {
			if (partial_sum + arr[i] <= mid) {
				partial_sum += arr[i];
			}
			else {
				partial_sum = arr[i];
				partial_cnt++;
			}
		}

		if (partial_cnt <= m) {
			min = mid;
			right = mid - 1;
		}
		else {
			left = mid + 1;
		}
	}

	printf("%d\n", min);

	return 0;
}

:bookmark: REFERENCE
인프런 | it 취업을 위한 알고리즘 문제풀이 (with C/C++) : 코딩테스트 대비

[Design Pattern] GoF 행위 패턴 - 옵서버 패턴(Observer Pattern)

Wed, 27 Jan 2021 00:00:00 +0000

옵서버 패턴(Observer Pattern)

GoF 디자인 패턴 중 행위 패턴에 해당한다.
객체의 상태 변화를 관찰하여 변화가 발생하면 변화를 통지받고 자동으로 갱신될 수 있게 한다. 주로 분산 이벤트 핸들링 시스템을 만들 때 사용한다.

사용법

어떤 객체의 변화로 인해 다른 객체가 변경되어야 하는데, 프로그래머들은 얼마나 많은 객체들이 변경되어야 하는지 몰라도 될 때
외부에서 발생한 이벤트에 대해 결과를 처리해야 할 때

구조

데이터의 변화가 발생할 Subject는 Observer들을 알고 있다.
Subject는 변화가 발생하면 Observer에게 notify한다.

장점

Subject와 Observer 클래스 사이에는 추상적인 결합도만 존재함
브로드캐스트 방식의 교류 가능 : Subject는 변화 발생 시 구체적인 수신자를 지정할 필요가 없다. 상태가 변화했다는 사실만 전달하면 변화를 처리할지 말지는 Observer가 결정한다.

예제

클래스 다이어그램

구현

Observable에 Observer를 등록한다. Observable에 변화가 생기면 프로그래머가 직접 상태를 업데이트해주는 것이 아니라, Observable이 직접 등록된 Observer들에게 변화를 알린다.(notify)
Observer는 알림을 받으면 그에 따른 작업을 수행한다.

import subject.IntegerObservable;
import observer.concrete.CircleObserver;
import observer.concrete.StarObserver;

public class Main {
    public static void main(String[] args) {
        IntegerObservable observable = new IntegerObservable();
        StarObserver starObserver = new StarObserver();
        CircleObserver circleObserver = new CircleObserver();

        observable.registerObserver(starObserver);
        observable.registerObserver(circleObserver);

        System.out.println("\n>> Data Changed");
        observable.setData(2);

        System.out.println("\n>> Data Changed");
        observable.setData(5);

        observable.unregisterObserver(starObserver);
        observable.unregisterObserver(circleObserver);

        System.out.println("\n>> Data Changed");
        observable.setData(10);
    }
}

[실행 결과]
>> Data Changed
<< Star Draw : **
<< Circle Draw : oo

>> Data Changed
<< Star Draw : *****
<< Circle Draw : ooooo

>> Data Changed

소스 코드

전체 소스 코드

package subject;

import observer.Observer;

import java.util.ArrayList;

public class Observable {

    private ArrayList<Observer> observerCollection = new ArrayList<>();

    public void registerObserver(Observer observer) {
        observerCollection.add(observer);
    }

    public void unregisterObserver(Observer observer) {
        observerCollection.remove(observer);
    }

    void notifyObservers() {
        for(Observer observer : observerCollection) {
            observer.update(this);
        }
    }
}

package subject;

public class IntegerObservable extends Observable{

    private int data;

    public int getData() {
        return data;
    }

    public void setData(int data) {
        this.data = data;
        notifyObservers();
    }
}

package observer.concrete;

import observer.Observer;
import subject.IntegerObservable;
import subject.Observable;

public class StarObserver implements Observer {
    @Override
    public void update(Observable observable) {
        System.out.print("<< Star Draw : ");
        for (int i = 0; i < ((IntegerObservable) observable).getData(); i++) {
            System.out.print("*");
        }
        System.out.println();
    }
}

package observer.concrete;

import observer.Observer;
import subject.IntegerObservable;
import subject.Observable;

public class CircleObserver implements Observer {
    @Override
    public void update(Observable observable) {
        System.out.print("<< Circle Draw : ");
        for (int i = 0; i < ((IntegerObservable) observable).getData(); i++) {
            System.out.print("o");
        }
        System.out.println();
    }
}

:bookmark: REFERENCE
에릭 감마 외 3명, 「GoF의 디자인 패턴」, 피어슨에듀케이션코리아
옵저버 패턴

[Design Pattern] GoF 생성 패턴 - 팩토리 메소드 패턴(Factory Method Pattern)

Tue, 26 Jan 2021 00:00:00 +0000

팩토리 메소드 패턴(Factory Method Pattern)

GoF 디자인 패턴 중 생성 패턴에 해당한다.
수퍼클래스에 알려지지 않은 클래스에 대해 서브클래스에서 어떤 객체를 생성할 지 결정하도록 하는 패턴이다. 수퍼클래스는 추상메소드 create를 정의하고, 서브클래스가 이를 재정의하여 객체를 생성한다. 이 때의 create메소드를 팩토리 메소드라고 한다.
추가로, 서브클래스는 수퍼클래스를 상속하지만 확장하지는 않는다는 점에 유의해야 한다.

사용법

어떤 클래스가 자신이 생성해야 하는 객체의 클래스를 알지 못할 때
객체의 생성을 서브클래스에게 위임하고 싶을 때

구조

Creator_{수퍼클래스}를 정의하고 이를 상속받은 ConcreteCreator_{서브클래스}를 구현한다.
ConcreteCreator는 factoryMethod()를 override하여 실체화하고 Product의 인스턴스를 반환한다.
어떤 타입의 객체를 생성해야 하는지를 서브클래스가 결정할 수 있게 된다.

장점

객체별로 서로 다른 메소드 제공
병렬적인 클래스 계통을 연결할 수 있음

예제

클래스 다이어그램

패키지 구조

구현

Creator_{수퍼클래스}를 상속받아 구체화한 클래스에서 Shape을 생성하는 메소드인 createShape()를 재정의한다. Creator의 팩토리 메소드를 통해 알맞은 클래스의 인스턴스를 생성하여 반환할 수 있다.

CircleCreator circleCreator = new CircleCreator();
RectangleCreator rectangleCreator = new RectangleCreator();

Shape circle = circleCreator.createShape();
circle.print();

Shape rectangle = rectangleCreator.createShape();
rectangle.print();

[실행 결과]
Create Circle...
Draw Circle...
>> Circle

Create Rectangle...
Draw Rectangle...
>> Rectangle

소스 코드

전체 소스 코드

package creator.abst;

import product.abst.Shape;

public abstract class ShapeCreator {

    public Shape createShape(){
        Shape shape = create();
        draw();
        return shape;
    }

    /* factory method */
    public abstract Shape create();

    /* operation */
    public abstract void draw();
}

package creator.concrete;

import creator.abst.ShapeCreator;
import product.abst.Shape;
import product.concrete.Circle;

public class CircleCreator extends ShapeCreator {
    @Override
    public Shape create() {
        System.out.println("Create Circle...");
        return new Circle();
    }

    @Override
    public void draw() {
        System.out.println("Draw Circle...");
    }
}

package product.abst;

public interface Shape {
    void print();
}

package product.concrete;

import product.abst.Shape;

public class Circle implements Shape {
    @Override
    public void print() {
        System.out.println(">> Circle\n");
    }
}

import creator.concrete.CircleCreator;
import creator.concrete.RectangleCreator;
import product.abst.Shape;

public class Main {
    public static void main(String[] args) {
        CircleCreator circleCreator = new CircleCreator();
        RectangleCreator rectangleCreator = new RectangleCreator();

        Shape circle = circleCreator.createShape();
        circle.print();

        Shape rectangle = rectangleCreator.createShape();
        rectangle.print();
    }
}

:bookmark: REFERENCE
에릭 감마 외 3명, 「GoF의 디자인 패턴」, 피어슨에듀케이션코리아
팩토리 메서드 패턴

[Design Pattern] GoF 생성 패턴 - 빌더 패턴(Builder Pattern)

Tue, 19 Jan 2021 00:00:00 +0000

빌더 패턴(Builder Pattern)

GoF 디자인 패턴 중 생성 패턴에 해당한다.
빌더 패턴은 복잡한 객체를 생성하는 클래스와 표현하는 클래스를 분리하여, 동일한 절차에서도 서로 다른 표현을 생성하는 방법을 제공한다.

사용법

객체의 생성 알고리즘이 조립 방법에 독립적일 때
합성할 객체들의 표현이 서로 다르더라도 생성 절차에서 표현 과정을 지원해야할 때

구조

Builder_{추상클래스}를 정의하고 이를 상속받은 ConcreteBuilder_{서브클래스}를 구현한다.
Product의 일부가 build될 때마다 Director는 Builder에 통보한다.
Builder는 Director의 요청을 처리해 Product에 부품을 추가한다.

장점

표현을 다양하게 변경할 수 있음
생성과 표현 코드를 분리함
복합 객체를 생성하는 절차를 세밀하게 나눌 수 있음

예제

클래스 다이어그램

패키지 구조

구현

추상 클래스인 ToyBuilder에서 Director가 요청하는 build 연산을 정의한다. ToyBuilder를 상속받은 ConcreteBuilder_{(PoohBuilder, ZzangGuBuilder)}가 필요한 표현을 override한다. ConcreteBuilder는 Toy의 부품들을 조립하고 Director는 조립이 완성된 Toy를 반환한다.

(1) Pooh Builder

Director director = new Director();
PoohBuilder poohBuilder = new PoohBuilder();

director.setToyBuilder(poohBuilder);

Toy toy = director.constructToy();
System.out.println(toy);

[실행 결과]
<Pooh>
hair = Yellow
clothes = Red short sleeved T-shirt
pants = null
shoes = null

(2) ZzangGu Builder

Director director = new Director();
ZzangGuBuilder zzangGuBuilder = new ZzangGuBuilder();

director.setToyBuilder(zzangGuBuilder);

Toy toy = director.constructToy();
System.out.println(toy);

[실행 결과]
<ZzangGu>
hair = Short black
clothes = Red short sleeved T-shirt
pants = Yellow shorts
shoes = null

소스 코드

전체 소스 코드

/* Builder */
package builder;

import product.Toy;

public abstract class ToyBuilder {
    protected Toy toy;

    public Toy getToy() {
        return toy;
    }

    public ToyBuilder create() {
        toy = new Toy();
        return this;
    }

    public abstract ToyBuilder buildName();
    public abstract ToyBuilder buildHair();
    public abstract ToyBuilder buildClothes();
    public abstract ToyBuilder buildPants();
    public abstract ToyBuilder buildShoes();
}

/* Concrete Builder */
package builder;

public class PoohBuilder extends ToyBuilder {
    @Override
    public ToyBuilder buildName() {
        toy.setName("Pooh");
        return this;
    }

    @Override
    public ToyBuilder buildHair() {
        toy.setHair("Yellow");
        return this;
    }

    @Override
    public ToyBuilder buildClothes() {
        toy.setClothes("Red short sleeved T-shirt");
        return this;
    }

    @Override
    public ToyBuilder buildPants() {
        return this;
    }

    @Override
    public ToyBuilder buildShoes() {
        return this;
    }
}

/* Director */
package director;

import builder.ToyBuilder;
import product.Toy;

public class Director {
    private ToyBuilder toyBuilder;

    public void setToyBuilder(ToyBuilder toyBuilder) {
        this.toyBuilder = toyBuilder;
    }

    public Toy constructToy() {
        return toyBuilder.create()
                .buildName()
                .buildHair()
                .buildClothes()
                .buildPants()
                .buildPants()
                .getToy();
    }
}

import builder.PoohBuilder;
import builder.ZzangGuBuilder;
import director.Director;
import product.Toy;

public class Main {
    public static void main(String[] args) {
        Director director = new Director();

        PoohBuilder poohBuilder = new PoohBuilder();
        ZzangGuBuilder zzangGuBuilder = new ZzangGuBuilder();

        director.setToyBuilder(poohBuilder);
        //director.setToyBuilder(zzangGuBuilder);

        Toy toy = director.constructToy();

        System.out.println(toy);
    }
}

:bookmark: REFERENCE
에릭 감마 외 3명, 「GoF의 디자인 패턴」, 피어슨에듀케이션코리아
빌더 패턴

[Design Pattern] GoF 생성 패턴 - 싱글톤 패턴(Singleton Pattern)

Tue, 29 Dec 2020 00:00:00 +0000

싱글톤 패턴(Singleton Pattern)

GoF 디자인 패턴 중 생성 패턴에 해당한다.
어떤 클래스의 인스턴스는 하나임을 보장하는 패턴이다. 또한 그에 대한 전역적인 접근점을 제공한다.
주로 공통된 객체를 여러 곳에서 참조해야 하는 경우(ex. 데이터베이스 참조)에 사용한다.
자바에서는 생성자를 private으로 선언하고 getInstance()와 같은 함수를 통해 인스턴스를 제공해주는 것이 일반적이다. 코틀린에서는 싱글톤 패턴을 보장해주는 object 키워드가 존재한다.

사용법

클래스의 인스턴스가 하나임을 보장해야 할 때

구조

Singleton 클래스는 getInstance() 메소드를 통해 유일한 인스턴스를 제공한다.

장점

유일하게 존재하는 인스턴스로의 접근을 통제 : 인스턴스를 캡슐화하므로, 사용자의 접근을 제어할 수 있음
전역변수보다 좋음
인스턴스 개수를 변경하기 쉬움 : 만약 인스턴스가 여러 개 존재하도록 하고 싶다면, 여러 개의 인스턴스를 생성해서 각각의 인스턴스로 접근할 수 있도록 구현하면 된다

예제

구현

Singleton 클래스의 객체는 getInstance()를 통해 생성, 접근한다. 생성자의 접근제한자를 private으로 설정하고, 생성자가 호출될 때마다 count를 추가해 인스턴스의 생성 횟수를 확인한다.

public class Singleton {
    private static Singleton instance;
    private String name;
    private int count = 0;

    private Singleton() {
        count++;
        name = "This is the only reference : " + count;
    }

    public static Singleton getInstance() {
        if(instance == null){
            instance = new Singleton();
        }
        return instance;
    }
    public String getName() {
        return name;
    }
}

public class Main {
    public static void main(String[] args) {
        Singleton singleton_reference1 = Singleton.getInstance();
        System.out.println("First Instance Name : "+singleton_reference1.getName());

        Singleton singleton_reference2 = Singleton.getInstance();
        System.out.println("Second Instance Name : "+singleton_reference2.getName());
    }
}

[실행 결과]
First Instance Name : This is the only reference : 1
Second Instance Name : This is the only reference : 1

소스 코드

전체 소스 코드

:bookmark: REFERENCE
에릭 감마 외 3명, 「GoF의 디자인 패턴」, 피어슨에듀케이션코리아