일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 동적계획법
- 투 포인터
- 스택
- 문자열
- Network
- 그리디
- 구현
- 수학
- 플로이드-와샬
- Kotlin
- swea
- 백트래킹
- 후니의 쉽게 쓴 시스코 네트워킹
- 완전탐색
- CS
- 세그먼트 트리
- 유니온 파인드
- 프로그래머스
- java
- mst
- 위상정렬
- 에라토스테네스의 체
- 이분탐색
- dfs
- Effective Java
- JUnit 5
- 시뮬레이션
- 알고리즘
- BFS
- 백준
목록전체 글 (291)
반갑습니다!
11723번: 집합 첫째 줄에 수행해야 하는 연산의 수 M (1 ≤ M ≤ 3,000,000)이 주어진다. 둘째 줄부터 M개의 줄에 수행해야 하는 연산이 한 줄에 하나씩 주어진다. www.acmicpc.net 풀이 시간 초과를 피하기 위해 이것저것 다양한 시도를 해봤던 문제이다. 비트 연산으로 바로 해결할 수 있을 줄 알았는데, BufferedReader, BufferedWriter까지 사용해야 정답처리 된다. 코드 import java.io.BufferedReader import java.io.BufferedWriter import java.io.InputStreamReader import java.io.OutputStreamWriter fun main() { var s = 0 val br = Buff..
toString 의 일반 규약 ''간결하면서 사람이 읽기 쉬운 형태의 유익한 정보'를 반환해야함 모든 하위 클래스에서 이 메서드를 재정의할 것 toString 을 잘 구현한 클래스를 사용한 시스템은 디버깅하기 쉬움 toString 메서드는 객체를 println, printf, 문자열 연결 연산자(+), assert 구문에 넘길 때, 또는 디버거가 객체를 출력할 때 자동으로 호출됨 toString 을 제대로 정의하지 않으면 쓸모없는 메시지만 로그에 남음 toString 은 그 객체가 가진 주요 정보를 모두 반환하는게 좋음 toString을 구현하는 방법 toString 을 구현할 때면 반환값의 포맷을 문서화할지 정해야함 값 클래스라면 문서화하기를 권장 ex) 전화번호 클래스, 행렬 클..
equals 를 재정의한 클래스 모두에서 hashCode 도 재정의해야 함 그렇지 않으면 hashCode 일반 규약을 어기게 되어 HashMap 이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제가 생김 equals 비교에 사용되는 정보가 변경되지 않았다면, 어플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야함. 단, 어플리케이션을 다시 실행한다면 이 값은 달라져도 상관없음. equals(Object)가 두 객체를 같다고 판단햇다면, 두 객체의 hashCode는 똑같은 값을 반환해야함 equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없음. 단, 다른 객체에 대해서..
equals 메서드는 재정의하기 쉬워 보이지만 잘못하면 자칫하면 끔찍한 결과를 초래하므로 특정 상황에 해당한다면 재정의하지 않는 것이 최선 재정의하면 안되는 상황 각 인스턴스가 본질적으로 고유할 때 값을 표현하는게 아니라 동작하는 개체를 표현하는 클래스일 때 ex) Thread 인스턴스의 '논리적 동치성(logical equality)'을 검사할 일이 없을 때 java.util.regex.Pattern 은 equals 를 재정의해서 두 Pattern 의 인스턴스가 같은 정규표현식을 나타내는지(논리적 동치성)를 검사 할 수 있음 설계자가 클라이언트에서 이 방식을 원하지 않거나 필요하지 않다고 판단하면 재정의하지 않는 것이 좋음 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞..
Java 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원이 많음 ex) InputStream , OutputStream , java.sql.Connection 이런 자원 중 상당수가 안전망으로 finalize 를 활용하고 있지만 그리 믿을만하지 않음(아이템 8) 전통적인 방법 전통적으로 자원을 제대로 닫힘을 보장하기 위해 try-finally가 쓰임 static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLine(); } finally { br.close(); } } 나쁘지 않은 방법..