좋은 아키텍처란? 풀려는 문제에 잘 어울리는 설계 코드 구조(ex. 클래스)가 시스템이 어떻게 동작하는지를 잘 이해할 수 있게 보여 준다 변화에 민감: 요구 사항이 진화함에 따라 쉽게 변경이 가능해야 한다 이런 게 쉬워야 한다 이해하기 왜 이렇게 되었는지 이유를 알기 유지하기 테스트하기 더 올바른 경향이 있다 성능 개선 작업을 더 부드럽게 해 준다 좋은 아키텍처의 방해물: 복잡성 복잡성 시스템을 이해하기 어렵고 수정하기 어렵게 만드는 소프트웨어 구조에 관련된 모든 것 복잡성 ≠ 코드의 줄 수 징후 변경 증폭: 작은 변경 → 여러 곳의 많은 편집 인지적 부하: 작은 변경 → 많은 선수 지식을 알아야 함 알 수 없는 무지: 작은 변경 → 알 수 없는 결과들 복잡성을 조장하는 세 가지 요인 의존성 코드가 독립적으로 이해되고 수정될 수 없을 때 없앨 수는 없으나, 최소화되어야 함 불명확함 중요한 정보가 불명확할 때 비용: 지금 10~20% 적게 들더라도 일부 비용은 이자로 영원히 남게 될…

Single Responsibility Principle: 단일 책임 원칙 응집도에 대한 기준 “각 소프트웨어 모듈은 변경의 이유가 단 하나여야만 한다” == “하나의 모듈은 오직 하나의 액터에 대해서만 책임져야 한다” 1974년 다익스트라에 의해 제안된 개념인 관심사의 분리의 다른 표현 하나의 클래스가 하나의 일만 해야 한다는 뜻이 아님에 유의(메소드는 그래야 함) Open-Closed Principle: 개방-폐쇄 원칙 “소프트웨어 모듈은 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다” 열려 있다: 데이터 구조에 필드를 추가하거나, 함수에 새로운 요소를 추가하는 것이 가능해야 함 닫혀 있다: 내부 코드를 변경해도 이를 사용하는 외부 모듈에는 영향을 미치지 않아야 함 멤버 변수를 private / protected로 선언: 내부 데이터의 변경이 클래스 사용자에게 의도치 않은 영향을 주지 않도록 글로벌 변수 피하기: 글로벌 변수를 참조하는 모듈이나 클래스가 외부 값에 의존…

정의 배열은 순차적으로 연결된 공간에 데이터를 나열하는 데이터 구조 링크드 리스트는 필요할 때마다 데이터를 추가할 수 있는 구조 떨어진 곳에 존재하는 데이터를 화살표로 연결해서 관리하는 데이터 구조 구조 노드: 데이터 저장 단위(데이터 값, 포인터)로 구성 포인터: 각 노드 안에서 다음이나 이전의 노드와의 연결 정보를 가지고 있는 공간 데이터 + 다음 데이터를 가리키는 주소로 구성 장점 미리 데이터 공간을 할당하지 않아도 됨 단점 연결을 위한 별도 데이터 공간이 필요하므로 저장 공간 효율이 높지 않음 연결 정보를 찾는 시간이 필요하므로 접근 속도가 느림 중간 데이터 삭제 시 앞뒤 데이터의 연결을 재구성해야 하는 부가적인 작업 필요 이중 연결 리스트 양방향으로 연결되어 노드 탐색이 양쪽으로 모두 가능 한 노드에 데이터와 함께 이전 데이터 주소와 이후 데이터 주소를 가짐

정의 알고리즘의 실행 속도 반복문이 지배함 알고리즘 성능 표기법 빅 오 표기법 알고리즘 최악의 실행 시간을 표기 가장 많이/일반적으로 사용함 아무리 최악의 상황이라도 이 정도 성능은 보장한다는 의미이기 때문 오메가 표기법 최상의 실행 시간 세타 표기법 평균 실행 시간 Big-O 표기법 O(입력) 입력 n에 따라 결정되는 시간 복잡도 함수 O(1), O(logn), O(n), O(nlogn), O(n^2), O(2^n), O(n!) 등으로 표기함 입력 n의 크기에 따라 기하급수적으로 시간 복잡도가 늘어날 수 있음 O(1) < O(logn) < O(n) < O(nlogn) < O(n^2) < O(2^n) < O(n!) 단순하게 입력 n에 따라 몇 번 실행이 되는지 계산하면 됨 n이 1이든, 100이든, 1000이든, 10000이든 실행을 O(1) 무조건 2회(상수회) 실행한다 O(n) n에 따라 n + 10번, 3n + 10번 등 실행한다 O(n^2) n에 따라 n^2번, n^2 + …