Study

2023년 8월 26일 알고리즘 문제풀이 문제 1 프로그래머스 전력망을 둘로 나누기 문제 링크 1차 시도 나의 생각 한 간선이 없어질 때마다 값을 모두 구한 후 가장 절대값이 작을 때를 찾았다. 결과 정답 코드 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 from collections import deque def solution(n, wires): answer = n d = len(wires) for i in range(d): arr = deque() arr.append(0) graph = [[] for _ in range(n)] visited = [False for _ in range(n)] visited[0] = True for j in range(d): if j == i: continue else: a,b = wires[j] graph[a-1].append(b-1) graph[b-1].append(a-1) while arr: now = arr.popleft() for x in graph[now]: if not visited[x]: visited[x] = True arr.append(x) cnt = visited.count(True) cnt = abs(n-2*cnt) answer = min(answer,cnt) return answer 문제 2 프로그래머스 쿼드압축 후 개수 세기 문제 링크 ...

책너두 5기 23일차 로버트 C. 마틴의 클린코드 p. 206 ~ p.215 내용 정리 11. 시스템 순수 자바 AOP 프레임워크 순수자바 관점을 구현하는 스프링 AOP, JBoss AOP 등과 같은 여러 자바 프레임워크는 내부적으로 프록시를 사용한다. 스프링은 비즈니스 논리를 POJO(Plain Old Java Object)로 구현한다. POJO는 도메인에 초점을 맞춰서 테스트가 쉽고 간단하며, 상대적으로 단순하기 때문에 사용자 스토리를 올바로 구현하기 쉽고 미래 스토리에 맞춰 코드를 보수하고 개선하기 편하다. AspectJ 관점 관심사를 관점으로 분리하는 가장 강력한 도구는 AspectJ 언어이다. 이것은 언어 차원에서 과넞ㅁ을 모듈화 구성으로 지원하는 자바 언어 확장이다. 관점을 분리하기 좋지만 새 도구를 사용하고 새 언어 문법과 사용법을 익혀야 하는 단점이 있다. 하지만 ‘애너테이션 폼’은 이 부담을 어느정도 완화한다. ...

2023년 8월 25일 알고리즘 문제풀이 문제 1 백준 3055 문제 링크 1차 시도 나의 생각 물을 따로 생각하지 말고 이미 방문해서 방문할 수 없는 곳으로 처리한다면 크게 복잡하지 않을 수도 있겠다는 생각을 했다. 따라서 고슴도치가 이동할 곳을 BFS로 탐색하되, 방문처리를 통해 물이 있는 곳과 바위가 있는 곳을 표시하면 되겠다고 생각했다. 주어진 예시는 답을 출력했는데, 고슴도치가 다음 턴에 물이 찰 곳으로 이동할 수 없는 조건이 적용되지 않았다. 따라서 이동할 수 없는 경우가 누락되어 오답처리되었다. ...

책너두 5기 22일차 로버트 C. 마틴의 클린코드 p.198 ~ p.205 내용 정리 11. 시스템 시스템 제작과 시스템 사용을 분리하라 Main 분리 시스템 생성과 시스템 사용을 분리하는 방법 중 하나는, 생성과 관련한 코드는 모두 main이나 main이 호출하는ㄴ 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정하는 것이다. 팩토리 때로는 객체가 생성되는 시점을 애플리케이션이 결정할 필요도 생긴다. 의존성 주입 의존성 주입(Dependency Injection)은 제어 역전(Inversion of Control, IoC) 기법을 의존성 관리에 적용한 메커니즘이다. 제어 역전에서는 한 객체가 맡은 보조 책임을 새로운 객체에레 전적으로 떠넘긴다. 새로운 객체는 넘겨받은 책임만 맡으므로 단일 책임의 원칙을 지키게 된다. 초기 설정은 시스템전체에서 필요하므로 대개 ‘책임질’ 메커니즘으로 ‘main’ 루틴이나 특수 컨테이너를 사용한다. ...

2023년 8월 24일 알고리즘 문제풀이 문제1 백준 1916 문제 링크 1차 시도 나의 생각 이전에 공부한 다익스트라로 풀면 되겠다고 생각했다. 출발지부터 각 도착지까지 비용을 표시하는 배열을 만들고 최소값으로 업데이트하였다. 그런데 이상하게 오답처리가 된다. 이유를 찾아봐야겠다. 결과 오답 코드 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 import sys from heapq import heappop, heappush n = int(sys.stdin.readline()) m = int(sys.stdin.readline()) graph = [[0 for _ in range(n+1)] for _ in range(n+1)] for _ in range(m): s, a, c = map(int, sys.stdin.readline().split()) graph[s][a] = c start, arrive = map(int, sys.stdin.readline().split()) def search(x): cost = [10**9 for _ in range(n+1)] cost[x] = 0 arr = [] heappush(arr,[0, x]) while arr: price, now = heappop(arr) if price > cost[now]: continue for i in range(1, n+1): if not graph[now][i]: continue new_money = price + graph[now][i] if new_money < cost[i]: cost[i] = new_money heappush(arr,[new_money, i]) return cost ans = search(start) print(ans[arrive]) 2차 시도 나의 생각 원인을 찾아냈다. 나는 두 도시간의 비용을 인접행렬로 표현했다. 즉 행렬의 값이 두 도시의 이동 비용이다. 하지만 문제에서 각 도시 간의 노선이 하나라는 보장이 없다.. 그래서 두 도시간의 버스 비용이 중복해서 주어진다면 내 코드는 가장 마지막에 입력된 것만 나타내게 된다. 하지만 먼저 입력된 버스비용이 더 작다면? 내 코드에선 정답을 도출할 수 없었다. ...

책너두 5기 21일차 로버트 C. 마틴의 클린코드 p.189 ~ p.197 내용 정리 10. 클래스 변경하기 쉬운 클래스 변경으로부터 격리 객체 지향 프로그래밍에는 구체적인(concrete) 클래스와 추상(abstract) 클래스가 있다. 상세한 구현(코드)을 포함하는 것과 개념만 포함하는 것의 차이이다. 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험하므로 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다. 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다. 이는 각 시스템 요소가 다른 요소로부터, 변경으로부터 잘 격리되어 있다는 의미다. 11. 시스템 도시를 세운다면? 도시에는 큰 그림을 그리는 사람들도 있으며 작은 사항에 집중하는 사람들도 있다. 한 사람의 힘으로는 직접 관리할 수 없다. 도시가 돌아가는 이유는 적절한 추상화와 모듈화 때문이다. 시스템도 마찬가지다. ...

책너두 5기 20일차 로버트 C. 마틴의 클린코드 p.180 ~ p.188 내용정리 10. 클래스 변경하기 쉬운 클래스 대다수 시스템은 지속적인 변경이 가해지고 그때마다 시스템이 의도대로 동작하지 않을 위험이 따른다. 따라서 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지 않는다. 읽고나서 오늘 읽을 분량의 대부분은 java와 sql 관련 코드들로 가득했다.. 확실한건 새 기능을 추가할 때, 기존의 것이 변경되지 않도록 시스템을 구성하는 것이 중요하다는 것! ...

4.분할정복 4.4 점화식을 풀기 위한 재귀 트리 방법 **재귀 트리(recursion tree)**에서는 각 노드가 재귀 호출되는 하위 문제 하나의 비용을 나타낸다. 트리의 각 레벨마다 그 비용을 합한 후 모든 레벨당 비용을 합한다. 예시: T(n) = 3T(n/4)+cn^2 T(n) 은 cn^2 + T(n/4) 3개로 이루어진다. 각 T(n/4)는 c(n/4)^2 + T(n/16) 3개로 이루어 진다. 즉 맨 위부터 각 레벨은 cn^2 1개, c(n/4)^2 3개, c(n/16)^2 9개 .. 로 반복됨을 알 수 있다. 이것이 어느정도 깊이까지 반복될까? 크기를 살펴보면 n -> n/4 -> n/16 이므로 레벨 i 에서는 n/(4^i) 임을 유추할 수 있다. 따라서 4^i = n 일때까지 반복되므로 i = log_4(n) 이라는 정수일때 까지 반복된다. i는 0단계부터 였으므로 총 횟수 log_4(n) + 1개 이다. 레벨 i = log_4(n) 이다. ...

책너두 5기 19일차 로버트 C. 마틴의 클린코드 p.170 ~ p.179 내용 정리 10. 클래스 코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기는 어렵다. 클래스 체계 자바에선 일반적으로 추상화 단계가 순차적으로 내려간다. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 하지만 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. 클래스는 작아야 한다! 클래스는 우선적으로 작아야 한다. 함수는 물리적인 행 수로 크기를 측정했지만, 클래스는 맡은 책임(RDD)을 기준으로 한다. 메서드 수가 작더라도 책임이 많읗 수 있다. 클래스 이름이 해당 클래스 책임을 기술해야 하는데, 작명이 간결하지 않다는 것은 보통 크기가 너무 크기 때문이다. ...

책너두 5기 18일차 로버트 C. 마틴의 클린코드 p.161 ~ p.169 내용정리 9. 단위 테스트 깨끗한 코드 도메인에 특화된 테스트 언어 숙련된 개발자라면 자기 코드를 좀 더 간결하고 표현력이 풍부한 코드로 리패터링해야 마땅하다. 이중 표준 테스트 API 코드에 적용하는 표준은 단순하고, 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다. 실제 환경이 아니라 테스트 환경에서 돌아가는 코드이기 때문이다. 임베디드 시스템에선 컴퓨터 자원과 메모리가 제한적일 가능성이 높지만 테스트 환경은 그럴 가능성이 낮다. 이것이 이중 표준의 본질이다. 코드의 깨끗함과는 철저히 무관하다. ...