목록전체 글 (314)
ecsimsw
HashSet의 출력이 고정된 것 같아 (@조엘) 우아한테크코스에서 함께 공부하는 친구가 좋은 대화 주제를 찾아주었다. 어느날 찾아와서는 HashSet의 순서에도 뭔가 규칙이 있을 것 같다는 얘기를 하는 것이다. public class HashSetExample { public static void main(String[] args) { HashSet hashSet = new HashSet(); hashSet.add("1"); hashSet.add("2"); hashSet.add("3"); hashSet.add("4"); hashSet.add("5"); hashSet.add("6"); hashSet.add("7"); hashSet.add("8"); hashSet.add("9"); hashSet.add("..
0. '좋은 코드'을 먼저 정의하자. 성능이 우선시 되어야 하는 상황, 가독성이 우선시 되어야 하는 상황 꼼꼼한 예외처리와 테스트가 우선시 되어야하는 상황, 빠르게 구현이 먼저 필요한 상황 객체지향, 테스트 코드, 성능을 생각하다가 가독성이 떨어지는 상황을 만들고 싶진 않다. 1. 불변 객체를 만들자 객체를 신뢰할 수 있다. Thread-safe하다. 참조가 꼬이는 일이 없다. Collections.unmodifiableList 보다는 방어적 복사를 사용한다. (참조 자체를 끊는다) 2. 컨트롤러의 다이어트가 필요하다. 컨트롤러는 조립하는 역할로 생각한다. 컨트롤러에 속성를 두지 않는다. / 상태를 만들지 않는다. 컨트롤러가 더럽다면 로직을 추상화해서 관련 객체와 로직을 포함하는 도메인 객체 또는 서비스..
배열, 리스트 선택의 근거 잡기 같은 타입의 여러 객체를 단순히 참조만 하는 용도에는 배열이 좋다고 생각했다. 리스트보다 배열이 메모리 관리에 유리하다는 자료구조 책의 한 문장을 기억했지 그 이상을 알려하지 않았다. 배열과 리스트 중 어떤 것을 사용해야하는 지 선택의 근거를 나름대로 잡아보려 한다. 배열보다는 리스트를 사용하라 'Effective Java 규칙 28. 배열보다는 리스트를 사용하라'는 배열보다 리스트 사용을 권장하고 있다. 그 이유를 공부해왔다. 아래처럼 배열을 사용할 경우, ArrayStroreException을 컴파일 시점에선 알 수 없다. 배열은 공변형이고, 런타임에서야 원소의 자료형이 결정되기 때문에, 런타임에서야 그 실수가 드러난다. Object[] objArr = new Long..
oracle docs - Collections.unmodifiableList() Returns an unmodifiable view of the specified list. This method allows modules to provide users with "read-only" access to internal lists. Query operations on the returned list "read through" to the specified list, and attempts to modify the returned list, whether direct or via its iterator, result in an UnsupportedOperationException. UnmodifiableList..
Variable 'i' should be final or effectively final 자바에서 람다식과 inner class에서는 final 변수 또는 effectively final 변수만 접근된다. 충분히 가능할 것만 같은 코드가 왜 컴파일 에러를 만드는지, effectively final 변수는 뭔지 정리해보려고 한다. public static void testLamda(String[] args) { int i = 0; Runnable testExpression = () -> i++; } // Variable used in lambda expression should be final or effectively final 람다 캡쳐링 아래 코드를 한번 보자. class test { public s..
자바에서의 열거형(enums) 처음 자바를 배웠을 때, annotation와 함께 가장 신기한 개념이었다. 어떻게 동작하는지도 모르고, 그저 사용 방식을 외워 사용해왔던 것 같아, 이번 포스팅을 정리하면서 좀 더 스스로 명확히 할 수 있도록 공부하려고 한다. 더하여 열거형의 조상 java.lang.Enum 타입을 흉내 내 보았다. 타입에 안전한 열거형 (Typesafe enum) C언어의 Enum은 단순히 이름과 상수를 매핑하는 것에 가깝다. 이를 테면, 아래 C언어에서의 열거형 예시에서 DayOfweek.Tuesday와 Numers.Three 둘 다 상수 2가 할당이 되어있으므로, 논리적으로는 맞지 않으나 C언어에서는 '같다'로 처리된다. #include enum DayOfWeek { Sunday = ..
IP 주소가 부족하진 않을까? 2018년 말 기사를 보니, 010으로 시작하는 휴대폰 번호의 80% 이상이 이미 사용되어 고갈 시를 대비하고 있다고 한다. IP주소도 비슷하다. 엄청난 양의 노드가 생겼고, 앞으로는 더 많이 생길 것이다. 그렇게 되면 IP 주소가 부족하진 않을까? 서브넷팅 IPv4 주소는 네트워크 주소와 호스트 주소로 영역이 분리되어 있다. 32비트 중 일부는 네트워크 영역, 일부는 호스트 영역인 것이다. 이를 서브넷팅이라고 한다. 한 네트워크에 속하는 호스트의 개수를 줄여 라우팅 정보를 줄이기 위함이다. 다음과 같은 상황을 생각해보자. 한 택배 회사가 배송지를 분담하려고 한다. 지금까지는 '시', '구' 단위로만 택배를 처리해야 했다. 지금까지는 그렇게 불만이 없었는데, 어느 날 어떤 ..
IP주소가 있는데 MAC 주소가 왜 필요해? 제목에 많은 고민을 했다. IP 주소가 있는데 MAC 주소가 필요한 이유, MAC 주소와 IP 주소의 차이 등등,, 결론부터 말하면 이 글은 MAC 주소와 IP 주소가 둘 다 필요한 이유를 담고 있다. 나처럼 IP 주소나 MAC 주소 하나만으로 데이터 전달 목적지를 정하면 안 될까 하는 궁금증을 가진 독자들에게 내가 생각한 그 이유를 설명하고자 한다. 사용 계층이 다르다. IP 주소와 MAC 주소를 사용하는 계층이 다르다. IP 주소는 Network layer에서, MAC 주소는 Data Link 계층에서 사용된다. 위 그림의 Network 계층과 Data Link 계층의 프로토콜에서, Ethernet과 IP만 익숙하겠지만 실제로는 더 다양한 프로토콜이 존재한..