가끔 자기소개서를 작성하다보면 붙여넣기가 안돼서 힘들 때가 있다.

이럴 때 간단히 체크만 해주면 편리하게 복붙할 수 있다.

개발자 도구(F12  or  Ctrl + Shift + i) → F1 → Disable JavaScript 체크

한국사가 끝나고,

어제부터 코테 1일 1문제를 시작했다.

백준 9205번 (https://www.acmicpc.net/problem/9205) 문제를 푸는데,

BFS인줄 알고, 이차원 배열 맵을 만들어서 위치를 표시하고 사방탐색하면서 나아가도록 구현했는데 뭔가 이상하다는 느낌을 받았다.

검색해보니 플로이드 와샬 알고리즘으로 푸는 것이다.

오랜만에 푸니까 다 까먹었다.

플로이드 와샬은 모든 정점에서 모든 정점으로의 최단 경로를 구할 때 사용한다.

DP 기반으로 아래 두 거리 중 최솟값으로 갱신한다.

x 노드에서 y 노드로의 거리   vs   x 노드에서 k (= 거쳐가는 노드, 경유지) 로의 거리 + k 에서 y노드로의 거리 

3중 for 문 = 시간복잡도가 N³ 이라는 점을 유의하며 사용해야 한다. 

아래 블로그를 참고하면서 개념을 이해했다.

# 9205 (맥주 마시면서 걸어가기) Java 코드

import java.util.*;
import java.io.*;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringBuilder answer = new StringBuilder();
        int t = Integer.parseInt(br.readLine());
            
        while (t --> 0) {
            int n = Integer.parseInt(br.readLine());

            StringTokenizer st;
            List<Point> locations = new ArrayList<>(); // 상근이네 집, 편의점, 페스티벌 좌표 저장
            for (int i = 0; i < n + 2; i++) {
                st = new StringTokenizer(br.readLine());
                int x = Integer.parseInt(st.nextToken());
                int y = Integer.parseInt(st.nextToken());
                locations.add(new Point(x, y));
            }
            
            boolean[][] isAbleToGo = new boolean[n + 2][n + 2]; 

            for (int i = 0; i < n + 2; i++) {
                for (int j = i + 1; j < n + 2; j++) {
                    if (findManhattan(locations.get(i), locations.get(j)) <= 1000) {
                        isAbleToGo[i][j] = isAbleToGo[j][i] = true;
                    }
                }
            }

            for (int k = 0; k < n + 2; k++) { // Floyd Warshall
                for (int i = 0; i < n + 2; i++) {
                    for (int j = 0; j < n + 2; j++) {
                        if (isAbleToGo[i][k] && isAbleToGo[k][j]) isAbleToGo[i][j] = true;
                    }
                }
            }

            answer.append(isAbleToGo[0][n + 1] ? "happy" : "sad").append("\n"); 
        }
        
        System.out.print(answer);
     } 

    static int findManhattan(Point p1, Point p2) {
        return Math.abs(p1.x - p2.x) + Math.abs(p1.y - p2.y);
    }

    static class Point {
        int x;
        int y;

        public Point(int x, int y) {
            this.x = x;
            this.y = y;
        }
    }
}

2차는 체감상 1과목은 무난했는데, 2과목이 헷갈려서 애매했다.

솔직히 조금은 떨어질 것 같기도 했는데 ,, 다행이다! 

1차는 오픈북 온라인 시험이라 다들 듀얼 모니터로 족보 다운 받아서 옆에 두고, ctrl + f 하면서 풀라고 알려줬다.

그래서 신청하자마자 족보 pdf 하나만 다운 받고 그냥 시험 시작했는데,

막상 찾기 어려워서 당황했다.

이럴 때 생각나는 건 역시 지피티밖에 없다.

바로 지피티 친구한테 의존하면서 다 풀었다.

근데도 틀리는 문제가 몇 개 있었음 ㅡㅡ

그렇게 자신 있게 대답하더니 ,,

얘도 믿을만하지는 않다. 

하지만 어차피 60점만 넘기면 되니까 괜찮다.

2차는 문제은행이라고 해서 일주일 정도 하루에 1~2회차씩 cbt 돌리면서 외웠다.

리눅스 명령어에 매우 취약한 편이라, 뒤돌아서면 까먹었다.

그래서 노션에 오답 정리하면서 계속 쳐다보는 것도 도움이 된다.

보기에 엄청 중구난방인데, 뭐 내가 볼 때 이해가 잘 되기만 하면 되니까 ~

리눅스마스터 2급 응시료 너무 비싸다.

돈 주고 자격증 얻는 기분이다.

디자인 패턴 (Design Pattern)

⚙️ 소프트웨어 설계에서 자주 발생하는 문제에 대한 일반적이고 반복적인 해결 방법

⚙️ 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제

⚙️ 1995년 GoF(Gang of Four)라고 불리는 에릭 감마(Erich Gamma), 리차드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시디스(John Vlissides)가 구체화 및 체계화

⚙️ 바퀴를 다시 발명하지 마라(Don't reinvent the wheel) : 개발 과정 중 문제가 발생하면 새로 해결책을 구상하는 것보다 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 더 효율적

⚙️ 지금까지도 소프트웨어 공학이나 현업에서 가장 많이 사용되는 디자인 패턴

⚙️ 유형에 따라 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개 총 23개의 패턴으로 구성

장점

⚙️ 범용적인 코딩 스타일로 인해 구조 파악 용이

⚙️ 객체지향 설계 및 구현의 생산성을 높이는 데 적합

⚙️ 검증된 구조의 재사용을 통해 개발 시간과 비용 절약

⚙️ 개발자 간 원활한 의사소통 가능

⚙️ 설계 변경 요청에 대한 유연한 대처 가능

단점

⚙️ 초기 투자 비용 부담 가능성

⚙️ 객체지향을 기반으로 한 설계와 구현을 다루므로 다른 기반의 애플리케이션 개발에는 부적합

생성 패턴 (Creational Pattern)

객체의 생성과 관련된 패턴이다.

객체의 생성과 참조 과정을 캡슐화하여 객체가 생성되거나 변경되어도 프로그램의 구조에 큰 영향을 받지 않도록 하여 프로그램에 유연성을 더해준다.

구조 패턴 (Structural Pattern)

클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴이다.

구조가 복잡한 시스템을 개발하기 쉽게 도와준다.

행위 패턴 (Behavioral Pattern)

클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴이다.

하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화 할 수 있도록 도와준다.

정보처리기사 기출문제

22년 4월

GoF(Gang of Four) 디자인 패턴을 생성, 구조, 행동 패턴의 세 그룹으로 분류할 때, 구조 패턴이 아닌 것은?

① Adapter 패턴

② Bridge 패턴

③ Builder 패턴

④ Proxy 패턴

→ 답 : ③ 

22년 3월

GoF (Gang of Four) 디자인 패턴에서 생성(Creational) 패턴에 해당하는 것은?

① 컴포지트(Composite)

② 어댑터(Adapter)

③ 추상 팩토리(Abstract Factory)

④ 옵서버(Observer)

→  답 : ③

22년 3월

소프트웨어 설계에서 자주 발생하는 문제에 대한 일반적이고 반복적인 해결 방법을 무엇이라고 하는가?

① 모듈 분해

② 디자인 패턴

③ 연관 관계

④ 클래스 도출

→   답 : ②

21년 8월, 20년 9월

GoF(Gang of Four) 디자인 패턴과 관련한 설명으로 틀린 것은?

① 디자인 패턴을 목적(Purpose)으로 분류할 때 생성, 구조, 행위로 분류할 수 있다.

② Strategy 패턴은 대표적인 구조 패턴으로 인스턴스를 복제하여 사용하는 구조를 말한다.

③ 행위 패턴은 클래스나 객체들이 상호작용하는 방법과 책임을 분산하는 방법을 정의한다.

④ Singleton 패턴은 특정 클래스의 인스턴스가 오직 하나임을 보장하고, 이 인스턴스에 대한 접근 방법을 제공한다.

→  답 : ②

21년 5월

GoF(Gang of Four) 디자인 패턴에 대한 설명으로 틀린 것은?

① Factory Method Pattern은 상위클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위클래스에서 인스턴스를 생성하도록 하는 방식이다.

② Prototype Pattern은 Prototype을 먼저 생성하고 인스턴스를 생성하도록 하는 방식이다.

③ Bridge Pattern은 기존에 구현되어 있는 클래스에 기능 발생 시 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 한다.

④ Mediator Pattern은 객체간의 통제와 지시의 역할을 하는 중재자를 두어 객체지향의 목표를 달성하게 해준다.

→  답 : ③

21년 5월

Gof(Gang of Four) 디자인 패턴 중 생성 패턴으로 옳은 것은?

① Singleton Pattern

② Adapter Pattern

③ Decorator Pattern

④ State Pattern

→  답 : ① 

20년 9월

디자인 패턴 사용의 장단점에 대한 설명으로 거리가 먼 것은?

① 소프트웨어 구조 파악이 용이하다.

② 객체지향 설계 및 구현의 생산성을 높이는데 적합하다.

③ 재사용을 위한 개발 시간이 단축된다.

④ 절차형 언어와 함께 이용될 때 효율이 극대화된다. 

> 답 : ④

20년 9월

다음 내용이 설명하는 디자인 패턴은?

• 객체를 생성하기 위한 인터페이스를 정의하여 어떤 클래스가 인스턴스화 될 것인지는 서브 클래스가 결정하도록 하는 것
• Virtual-Constructor 패턴이라고도 함

① Visitor 패턴

② Observer 패턴

③ Factory Method 패턴 

④ Bridge 패턴

> 답 : ③

20년 8, 6월

디자인 패턴 중에서 행위적 패턴에 속하지 않는 것은?

① 커맨드(Command) 패턴

② 옵서버(Observer) 패턴

③ 프로토타입(Prototype) 패턴

④ 상태(State) 패턴

> 답 : ③

ㅠㅠ

이번에는 약 일주일 정도 열심히 공부했다.

유명한 민트책 샀는데 모든 자격증 교재가 그렇듯 사실상 거의 안 봤고,

1. 아답터 요약노트

2. 꿈꾸는라이언 요약노트

두 개 구매해서 봤다.

근데 민트책 구매하면 좋은 점 = QR로 기출문제 풀 수 있는 어플(데이터에듀PT)을 쓸 수 있다.

그래서 기출은 왔다 갔다 시간날 때 스마트폰으로 풀었다.

근데 구글링해서 기출 구할 수 있으면 굳이 책을 사야하나 싶다.

+

아답터 유튜브 봤다.

좋았다.

요시 !

25.05.17. (a.k.a. ADsP 시험날)

파워 P는 늦게 접수해서 이거 보러 서울까지 다녀왔다.

시험 끝나고 ↑ 여기 들어가면 집단지성으로 답을 맞춰볼 수 있어서 좋다.

가진게 정처기, SQLD, OPIc 밖에 없어서 ,,

이번 하반기 할 일 = 자격증 수집

ADsP 했고,

이제

리눅스마스터2급

한국사1급

컴활1급

빅데이터분석기사

+ 시간 되면 어학 1개 더 ,,?

이거 다 모으면 공기업 서류는 안 떨어질 것 같아.

한양대학교 이석복 교수님의 2017년 2학기 컴퓨터 네트워크 강의를 듣고 정리한 글입니다.

목차

• DNS 가 UDP 기반으로 동작하는 이유
• 소켓 (Socket)
• 소켓의 종류 (Two essential types of sockets)
• Socket Functions(TCP case)

DNS 가 UDP 기반으로 동작하는 이유

HTTP, DNS 둘 다 Application Layer Protocol 로서 Transport Layer Protocol 인 TCP 와 UDP 를 사용한다. HTTP 가 TCP 기반이라는 것은 잘 알려져 있다. 그렇다면 DNS 는 어떤 프로토콜을 사용할까 ? 직관적으로 생각하면 데이터가 유실되면 안 되기 때문에 TCP 를 사용할 것만 같다. 하지만  현재 DNS 는 UDP 를 사용한다. 그렇다면 데이터 유실을 감수하고도 왜 DNS 는 UDP 기반으로 동작하는 것일까 ? 실제 TCP 는 UDP 에 비해 데이터를 담고, 보내는 전송 과정에서 딜레이가 있다. DNS 는 단지 아주 크기가 적은 데이터인 주소만 알면 되는데, TCP 는 너무 오래 걸린다. 그럼  데이터 유실 문제는 어떻게 할까 ? HTTP 커뮤니케이션에서는 HTTP Response 내 데이터 양이 매우 많을 수도 있고, 대량의 데이터가 유실되는 것은 큰 문제가 될 수 있다. 그러나 DNS 의 경우 DNS Query 내 Response 에 들어가는 데이터 자체가 매우 작다. 호스트 네임을 전송하고, IP 주소를 받아오는 것이 끝이므로 데이터 자체가 몇 바이트 채 되지 않는다. 유실될 확률이 적을 뿐더러, 유실이 되더라도 큰 부담이 없다. 무엇보다 UDP 기반으로 동작하는 것이 빠르고, TCP 보다 현실적으로 훨씬 효율적이다. 따라서 DNS는 현재 UDP 기반으로 동작한다.

소켓 (Socket)

• An interface between applicatioin and network
  • The application creates a socket
  • The socket type dictates the style of communication
    • reliable vs best effort
    • connection-oriented vs connectionless
• Once configured, the application can
  • pass data to the socket for networt transmission
  • receive data from the socket (transmitted through the networt by some other host)

소켓의 종류 (Two essential types of sockets)

SOCK_STREAM

• a.k.a. TCP
• reliable delivery
• in-order guaranteed
• connection-oriented
• bidirectional

SOCK_DGRAM

• a.k.a.  UDP
• unreliable delivery
• no order guarantees
• no notion of "connection"
  • app indicates dest, for each packet
• can send or receive

Socket Functions (TCP case)

TCP 기반의 소켓 통신을 위한 C 언어 함수에 대해 알아본다.

아래와 같은 순서로 함수를 호출하여 클라이언트와 서버를 연결한다.

TCP Server 

• socket() :이 함수를 call 하며 Socket API 를 사용을 시작한다. socket 함수의 파라미터로 TCP Socket, UDP Socket 을 정할 수 있다.
• bind() :  생성한 Socket 을 몇 번 port 에 장착할지 정한다.
• listen() : 서버에 특화된 함수이다. 이 소켓을 듣는 용도로 쓰겠다는 것이다. 즉, 서버이므로 액션을 취하는 것이 아니라 클라이언트를 기다리는 것을 의미한다.
• accept() : bloking 함수이다. 클라이언트로부터 Request 가 올 때까지 기다린다.

blocks until connection from client

TCP Client

• socket() : 역시 Socket 을 시작한다.
• connect() : 상대 Server 에 TCP connection 을 맺는다. 서버 주소 등이 들어간다. bloking 함수이다.

TCP three-way handshaking

연결 후, TCP Client 는 write()  를 통해 데이터를 요청하고, TCP Server 는 read() 를 통해 데이터를 처리하는 것을 반복한다.

두 함수 역시 blocking  함수이다.

통신 완료 후, close() 를 통해 소켓을 종료한다.

UDP 기반 소켓 통신은 간단하다. Server 측에서 Socket 을 열고 Bind 하면, Client 측에서도 Socket 을 열고 바로 통신하면 된다.

Reference

캐시 일관성이란 각각 클라이언트의 로컬 캐시 데이터와 메인 공유 메모리의 데이터가 모두 일치하는 것을 의미한다. 캐시 일관성이 지켜지지 않는 상황을 두고 캐시 일관성 문제라고 한다.각 클라이언트가 자신 만의 로컬 캐시를 가지고 다른 여러 클라이언트와 메모리를 공유하고 있을 때, 캐시의 갱신으로 인해 데이터 불일치 문제가 발생할 수 있다. 이러한 문제를 방지하고, 캐시 일관성을 유지하기 위해서 사용하는 방법 중 하나는 Conditional GET 이다.

한양대학교 이석복 교수님의 2017년 2학기 컴퓨터 네트워크 강의를 듣고 정리한 글입니다.

목차

• 캐시 일관성 (Cache Coherence)
• Conditional GET
• DNS (Domain Name System)

캐시 일관성 (Cache Coherence)

캐시 일관성이란 각각 클라이언트의 로컬 캐시 데이터와 메인 공유 메모리의 데이터가 모두 일치하는 것을 의미한다. 캐시 일관성이 지켜지지 않는 상황을 두고 캐시 일관성 문제라고 한다. 각 클라이언트가 자신 만의 로컬 캐시를 가지고 다른 여러 클라이언트와 메모리를 공유하고 있을 때,  캐시의 갱신으로 인해 데이터 불일치 문제가 발생할 수 있다. 이러한 문제를 방지하고, 캐시 일관성을 유지하기 위해서 사용하는 방법 중 하나는 Conditional GET 이다.

Conditional GET

don't send object if cache has up-to-date cached version

• no object transmission delay
• lower link utilization

 if-modified-since: <date>  HTTP 요청 헤더는 날짜와 시간 정보를 담고 있으며, 조건부 요청이다. 서버는 지정된 날짜 이후 수정이 되었다면 HTTP Status 200 과 함께 요청된 리소스 (Object)를 돌려준다. 하지만 만약 수정되지 않은 리소스에 대한 요청은 리소스 없이 HTTP Status 304 (Not Modified) 응답을 한다.

여기까지는 HTTP 프로토콜에 대한 이야기이다.

이제부터 또 다른 애플리케이션 프로토콜인 DNS 에 대해 알아본다.

DNS (Domain Name  System)

How to map between IP address and name, and vice versa ?

• distributed database : implemented in hierarchy of many name servers
• application-layer protocol : hosts, name servers communicate to resolve names 

프로세스와 프로세스 간의 커뮤니케이션을 위해서는 다른 머신에 존재하는 프로세스를 지칭하기 위해 주소가 필요하다. 즉,  인터넷 상의 한 컴퓨터에서 다른 컴퓨터로 데이터를 주고 받으며 통신하기 위해서는 주소를 알아야 한다. IP 주소와 Port 번호가 바로 해당 주소라고 할 수 있다. Port 번호는 통상적으로 고정된 번호가 있다. 예를 들어 HTTP 는 80으로 고정되어 있다. 그러나 IP 주소는 32 bit 로 이루어진 고유한 주소이다. 이를 일일이 기억하기는 어렵다. 친구들에게 연락하기 위한 전화번호를 일일이 외우기 힘든 것처럼 말이다. 그래서 마치 전화번호부와 같이 알아보기 쉬운 영단어 (Name Server)를 각 주소와 매핑시키자는 생각에서 DNS 개념이 생겨났다. 예를 들어 구글의 Name Server는  www.google.com  이고, IP Address는 123.xxx... 인 것이다. 이는 좋은 방법이지만 문제는 세계의 모든 서버 정보가 저장된 하나의 데이터베이스에 Access 하여 사용하기 어렵다는 것이다. 데이터도 무수히 많고, 검색 시간도 방대하다. 또한, 비유를 하자면 DNS는 상대방에게 전화를 걸기 위한 준비 운동과 같다. 핵심은 상대방에게 전화를 거는 것이지만 이 DNS는 전화를 걸기 위해 전화번호부를 찾아보는 부가적인 행동이기 때문이다.

분산 시스템

무엇보다 만약 정전으로 인해 서버가 잠시 다운된다면 전세계 사람들은 웹 브라우저를 사용하는데 어려움을 겪게 될 것이라는 치명적인 문제 (SPOF)를 안고 있다. 따라서 지금은 분산 시스템으로 구조화되어 존재한다.

" SPOF (single point of failure, 단일 장애점) "

시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 요소를 말한다.

DNS Query 

도메인 이름을 웹 브라우저에 입력할 때 최종 사용자를 어떤 서버에 연결할 것인지를 제어한다.

이 요청을 쿼리라고 부른다.

DNS Query 방법에는 두 가지가 있다.

반복적 질의 (Iterative Query)

최종 IP 주소를 받을 때까지 요청과 응답을 계속해서 Local DNS 서버가 반복한다. 클라이언트 입장에서는 Root 에 접근할 일이 거의 없다.

재귀적 질의 (Recursive Query)

사용자가 Local DNS 서버에 Query 를 보내면 Local DNS 서버가 Root Name 서버에 Query를 보내고, Root Name 서버는 자신의 서버에 없다면 해당 TLD 서버에 요청하는 식으로, 실제 도메인 정보를 가지고 있는 서버까지  Query가 이동하여 IP 주소를 재귀적으로 얻는다.

실제 DNS 서버는 반복과 재귀를 함께 사용한다.

💡 DNS : a distributed, hierachical database

client wants IP for www.amazon.com  

• client queries root server to find com DNS server
• client queries .com DNS server to get amazon.com DNS server
• client queries amazon.com DNS server to get IP address for www.amazon.com  

💡 DNS : root name servers

contacted by local name server that ccan not resolve name 

• contacts authoritative name server if name mapping not known 
• gets mapping
• returns mapping to local name server

💡 TLD, authoritative servers

top-level domain (TLD) servers

• responsible for com, org, net, edu, aero, jobs, museums, and all top-level country domains (e.g. uk, fr)
• network solutions maintains servers for .com TLD
• educause for .edu TLD

authoriative DNS servers

• organization's own DNS server(s), providing authoritative hostname to IP mappings for organization's named hosts
• can be maintained by organization or service provider
• second-level domain (SLD) servers

DNS records

distributed db storing resource records (RR)

RR format : (name, value, type, ttl)

권한 있는 DNS 서버에 있는 명령으로서, 도메인에 연계된 IP 주소 및 해당 도메인에 대한 요청의 처리 방법에 대한 정보를 제공한다. 이 레코드는 DNS 구문이라고 하는 일련의 텍스트 파일로 구성된다. DNS  레코드에는 일반적으로 Name, Value, Type, TTL 이 있다.Type 에 따라 레코드가 의미하는 바가 결정이 된다. 여러 type 중, A 와 NS 가 있다.

type = A

• name is hostname
• value is IP address

type = NS

• name is domain
• value is hostname of authoritative name server for this domain

🔎 TTL (Time to live) 
 컴퓨터나 네트워크에서 데이터의 유효 기간을 나타내기 위한 방법이다. 

DNS 에서 권한 있는 네임서버는 특정 리소스 레코드의 TTL 값을 설정한다. 재귀적 (recursive) 캐시 네임서버가 권한있는 네임서버에 질의를 보낼 때, 캐시 네임서버는 그 레코드를 TTL 값에 해당하는 시간동안 캐시에 저장해 둔다. 

추후 스터브 리졸버(stub resolver)가 캐시 네임서버에 동일한 레코드에 대한 질의를 보냈을 때, 해당 레코드의 TTL 값이 아직 만료되지 않았다면 캐시 네임서버는 권한있는 네임서버에 질의를 보낼 필요 없이 캐시에 저장된 정보를 이용해 바로 응답을 하게 된다. 네임서버는 특정 도메인이 존재하지 않음을 나타내는 NXDOMAIN 응답에 대해서도 TTL 값을 가질 수 있다. 다만 이 경우에는 일반적으로 그 값이 최대 3시간 정도로 짧다.

TTL 값이 짧으면 상위의 권한있는 네임서버에 가해지는 부하가 커진다는 단점이 있지만, 반면에 메일 교환 레코드(mail exchange record)와 같이 주소 변경에 민감한 서비스에 적합하다는 장점을 가진다. 이 때문에 특정 서비스의 주소가 옮겨지는 경우, 이로 인한 혼란을 최소화하기 위해 DNS 관리자는 관련 레코드의 TTL 값을 낮춘다.

+ 읽어볼 글

Reference

로버트 마틴 (Robert C. Martin)이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 페더스 (Michael C. Feathers)가 두문자어 기억술로 소개한 것이다. 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다.

목차

1. SOLID (객체 지향 설계)
2. Single responsibility principle, SRP
3. Open/closed principle, OCP
4. Liskov substitution principle, LSP
5. Interface segregation principle, ISP
6. Dependency inversion principle, DIP

🔎 SOLID (객체 지향 설계)

컴퓨터 프로그래밍에서 SOLID란 로버트 마틴 (Robert C. Martin)이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 페더스 (Michael C. Feathers)가 두문자어 기억술로 소개한 것이다. 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다. SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때까지 소프트웨어 소스 코드를 리팩터링하여 코드 냄새를 제거하기 위해 적용할 수 있는 지침이다. 이 원칙들은 애자일 소프트웨어 개발과 적응적 소프트웨어 개발의 전반적 전략의 일부이다.

✔️ 단일 책임 원칙 (Single responsibility principle, SRP)

: 한 클래스는 하나의 책임만 가져야 한다.

✔️ 개방-폐쇄 원칙 (Open/closed principle, OCP)

: 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

✔️ 리스코프 치환 원칙 (Liskov substitution principle, LSP)

: 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 계약에 의한 설계를 참고하라.

✔️ 인터페이스 분리 원칙 (Interface segregation principle, ISP)

: 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. 인터페이스를 구체적이고 작은 단위로 분리하여 꼭 필요한 인터페이스만 상속해야 한다.

✔️ 의존관계 역전 원칙 (Dependency inversion principle, DIP)

: 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. 의존성 주입은 이 원칙을 따르는 방법 중 하나이다. 상위 모듈은 하위 모듈에 의존하면 안된다.

Single Responsibility Principle, SRP

• 단일 책임 원칙

• “ There should never be more than one reason for a class to change. ”

• 한 클래스는 하나의 책임 (axis of change)만 가져야 한다.

• 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나 뿐 이어야 한다.

• 책임은 “ 캡슐화 ” 한다.

•.응집도 (Cohesion)를 높이고 결합도 (Coupling)를 낮춘다.

• 가독성이 향상되고, 유지보수가 용이해진다.

• 다른 원칙들을 적용하는 기초가 된다.

📌 Extract Class

Extract Class는 마틴 파울러의 책 <Refactoring: Improving the Design of Existing Code>2에서 소개된 클래스를 분리하는 객체지향 리팩토링의 한 방법이다. 이 책에서 소개하는 대부분의 위험상황에 대한 해결방법은 직/간접적으로 SRP 원리와 관련이 있다. 항상 코드를 최상으로 유지한다는 리팩토링의 근본정신도 항상 객체들의 책임을 최상의 상태로 분배한다는 것에서 비롯되기 때문이다. Extract Class는 두 개의 클래스가 해야 할 일을 하나의 클래스가 하고 있는 경우, 새로운 클래스를 만들어서 예전 클래스에서 새로운 클래스로 옮기는 것을 의미한다. 객체지향 설계에서 클래스는 분명히 추상화되어야 하고, 명확한 책임을 가져야 한다.

Move Method

메소드가 자신이 정의된 클래스보다 다른 클래스의 기능을 더 많이 사용하고 있다면, 이 메소드를 가장 많이 사용하고 있는 클래스에 비슷한 몸체를 가진 새로운 메소드를 만들고, 이전 메소드는 간단한 위임으로 바꾸거나 완전히 삭제한다.

Move Field

필드가 자신이 정의된 클래스보다 다른 클래스에 의해 더 많이 사용되고 있다면, 타겟 클래스에 새로운 필드를 만들고 기존 필드를 사용하는 모든 부분을 변경한다.

Interface Segregation Principle, ISP

• 인터페이스 분리 원칙

• “ Clients should not be foreced to depend upon interfaces that they do not use. ”

• 범용 인터페이스보다 특정 클라이언트를 위한 인터페이스 여러 개를 선언한다.

• 시스템 내부 의존성을 약화시켜 리팩토링, 수정, 재배포를 쉽게 할 수 있도록 한다.

인터페이스 분리 원칙은 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙이다. 즉, 하나의 큰 인터페이스를 상속받기 보다는 인터페이스를 구체적이고 작은 단위들로 분리시켜 꼭 필요한 인터페이스만 상속하자는 의미이다. SRP는 클래스의 단일 책임을 강조한다면 ISP는 인터페이스의 단일 책임을 강조한다.

Dependency Inversion Principle, DIP

• 의존 관계 역전 원칙

• “High level modules should not depend upon low level modules. Both should depend upon abstractions.”

• “Abstractions should not depend upon details. Details should depend upon abstractions.”

• 추상화에 의존해야 하고, 구체화에 의존하면 안된다.

• 상위 모듈은 하위 모듈에 의존해서는 안된다.

• “상위와 하위 객체 모두 동일한 추상화에 의존해야 한다”는 객체지향 설계의 대원칙을 제공한다.

의존 관계 역전 원칙은 추상화에 의존하고, 세부 사항에 의존해서는 안된다는 원칙이다. 클래스 사이에 의존 관계는 당연히 존재하지만, 최대한 추상화된 클래스에 의존하라는 것이다. Java의 인터페이스와 같은 타입에 기반한 응용 프로그램을 작성하라는 의미이기도 하다. DIP의 키워드는 ‘IOS’, ‘훅 메소드’, ‘확장성’이다.

Reference

평범한 배낭이지만 절대 평범하지가 않다. 알고 보니 배낭 문제 (knapssack problem)로 Dynamic Programming의 대표적인 문제라고 한다. Knapsack Algorithm이라고도 불리는 배낭 문제는 두 가지 문제로 분류된다. 짐을 쪼갤 수 있는 경우와, 짐을 쪼갤 수 없는 경우이다. 전자는 Fraction Knapsack Problem이라고 하고, Greedy를 사용한다.

🔗 문제 링크

🔎 문제 풀이

평범한 배낭이지만 절대 평범하지가 않다. 

알고 보니 배낭 문제 (knapsack problem)로 Dynamic Programming의 대표적인 문제라고 한다.

Knapsack Algorithm이라고도 불리는 배낭 문제는 두 가지 문제로 분류된다.

짐을 쪼갤 수 있는 경우와, 짐을 쪼갤 수 없는 경우이다.

전자는 Fraction Knapsack Problem이라고 하고,  Greedy를 사용한다.

후자는 0/1 Knapsack Problem이라고 하고, 보통 DP를 사용한다.

나무위키와 블로그를 참고해서 배낭 문제에 대해 이해했다.

이 문제는 짐을 쪼갤 수 없는 경우이므로 DP로 푼다.

아래 블로그에 나오는 테이블 그림을 참고하면 이해하는데 도움이 된다.

Java 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        int N = Integer.parseInt(st.nextToken());
        int K = Integer.parseInt(st.nextToken());

        int[][] dp = new int[N + 1][K + 1];

        for (int i = 1; i <= N; i++) {
            st = new StringTokenizer(br.readLine());

            int W = Integer.parseInt(st.nextToken());
            int V = Integer.parseInt(st.nextToken());

            for (int j = 1; j <= K; j++) {
                if (j < W) {
                    dp[i][j] = dp[i - 1][j];
                    continue;
                }

                dp[i][j] = Math.max(V + dp[i - 1][j - W], dp[i - 1][j]);
            }
        }

        System.out.println(dp[N][K]);
    }
}

프랙탈 (Fractal)이란 ? 

일부 작은 조각이 전체와 비슷한 기하학적 형태를 말한다. 이런 특징을 자기 유사성이라고 한다. 즉, 자기 유사성을 갖는 기하학적 구조를 프랙탈 구조라고 한다. 프랙탈 구조는 자연물에서 뿐만 아니라 수학적 분석, 생태학적 계산, 위상 공간에 나타나는 운동모형 등 곳곳에서도 발견되어 자연이 가지는 기본적인 구조이다. 프랙탈은 수학적 도형으로도 연구되고 있다고 한다. 프랙탈 도형은 종종 컴퓨터 소프트웨어를 이용한 재귀적이거나 반복적인 작업에 의한 반복되는 패턴으로 만들어진다.

프랙탈 트리 (Fractal Tree)

프랙탈 구조가 나무의 모양인 프랙탈 트리를 Java를 이용해  재귀 함수로 그려볼 수 있다. 가지를 그리기 위해서 삼각함수를 이용한다. 

import java.awt.Frame;
import java.awt.Graphics;

/**
 * FractalTree.
*/

public class FractalTree extends Frame {
    int startX;
    int startY;
    int angle;
    int length;
    int rotate;
    int growth;
    int depth;

    /**
     * Constroctors.
     *
     * @param width width
     * @param height height
     * @param x x
     * @param y y
     * @param angle angle
     * @param length length
     * @param rotate rotate
     * @param growth growth
     */
    public FractalTree(int width, int height, int x, int y,
            int angle, int length, int rotate, int growth) {
        this.startX = x;
        this.startY = y;
        this.angle = angle;
        this.length = length;
        this.rotate = rotate;
        this.growth = growth;

        this.setSize(width, height);
    }

    /**
     * Paint branch.
     *
     * @param graphics graphics
     * @param startX startX
     * @param startY startY
     * @param degree degree
     * @param length length
     */
    public void branch(Graphics graphics, int startX, int startY, int degree, int length) {
        if (length > 1) {
            int endX = (int) (startX - length * Math.cos(Math.toRadians(degree)));
            int endY = (int) (startY - length * Math.sin(Math.toRadians(degree)));
            int branchLength = (int) (length * growth * 0.01);

            graphics.drawLine(startX, startY, endX, endY);
            branch(graphics, endX, endY, degree - rotate, branchLength);
            branch(graphics, endX, endY, degree + rotate, branchLength);
        }
    }

    @Override
    public void paint(Graphics graphics) {
        branch(graphics, startX, startY, this.angle, this.length);
    }

    public static void main(String[] args) {
        FractalTree tree = new FractalTree(500, 500, 250, 450, 90, 100, 30, 75);
        tree.setVisible(true);
    }
}

짠 !

Reference