진성 소프트

(Effective Java) 규칙15. 클래스와 멤버의 접근 권한을 최소화하라 잘 설계된 컴포넌트란 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다. 정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다. 정보은닉의 장점 대부분의 장점은 시스템을 구성하는 컴포넌트들을 서로 독립시켜서 개발, 테스트, 최적화, 적용, 분석, 수정을 개별적으로 할 수 있게 해준다. 1. 시스템의 개발 속도를 높임 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다. 2. 시스템 관리 비용을 낮춤..

(Effective Java) 규칙58. 전통적인 for 문보다는 for-each 문을 사용하라 전통적인 for문의 컬렉션, 배열 순회의 단점 아래 관용구들은 while문보다는 낫지만(규칙57) 가장 좋은 방법은 아니다. for(Iterator i = c.iterator(); i.hasNext()) { Element e = i.next(); ... // e로 무언가를 함 } for (int i = 0; i < a.length; i++) { ... // a[i]로 무언가를 한다. } 반복자와 인덱스 변수는 모두 코드를 지저분하게 할 뿐 진정 필요한 건 원소들뿐임 쓰이는 요소가 늘어나면 오류가 생길 가능성이 높아짐 컬렉션이냐 배열니야에 코드 형태가 상당히 달라짐 for-each 문 for-each 문의 정식..

들어가며 배열을 List로 변환하기 위해 Arrays.asList() 를 사용하여 remove() 메서들 사용하던 중 java.lang.UnsupportedOperationException: remove이라는 에러가 발생하였다. 이슈가 발생한 원인에 대해서 알아보고자 한다. 문제의 원인 Arrays.asList()이 반환하는 값은 고정 크기의 List를 반환하기 때문이다. API를 참고해보면 Arrays.asList: Returns a fixed-size list backed by the specified array. 즉, Arrays.asList()로 반환된 List는 구조를 변경할 수 없는 불변 List라는 것이다. 해결 방법 만약 Arrays.asList() 반환된 List의 구조를 변경하고 싶다면..

(Effective Java) 규칙57. 지역변수의 범위를 최소화하라 지역변수의 범위를 최소화 지역변수의 유효범위를 최소로 줄이면 코드 가독성과 유지보수성이 높아지고 오류 가능성은 낮아진다. 지역변수의 범위를 줄이는 방법 1. 가장 처음 쓰일 때 선언하기 미리 선언부터 해두면 코드가 어수선해져 가독성이 떨어짐 변수를 실제로 사용하는 시점엔 타입과 초기값이 기억나지 않을 수도 있음 그렇지 않으면 지역변수가 쓰이는 범위 보다 너무 앞서 선언하거나, 다 쓴 뒤에도 여전히 살아 있게 되기 쉬움 2. 거의 모든 지역변수는 선언과 동시에 초기화하기 만약 초기화에 필요한 정보가 충분하지 않다면 충분해질 때까지 선언을 미뤄야 함 단, try-catch문은 예외임 변수를 초기화하는 표현식에서 검사 예외를 던질 가능성이 ..

란 JavaFX 2.2에 새로 추가된 .fxml 파일 작성 사용하는 root Tag이다. contents... 를 사용하게 되면 FXML로 재사용 가능한 컴포넌트를 작성하는 데 도움을 준다고 한다. 재사용성? 예를 들어, HBox안에 TextField와 Button이 들어 있는 컨포넌트를 작성한다고 해보자.(fx:root 사용 하지 않고) 그럼 아래와 같이 작성할 수 있을 것이다. VBox vbox = new VBox(); vbox.getChildren().add(new MyComponent()); 그리고 MyComponent Java Class는 아래와 같이 작성할 것이다. public class MyComponent extends HBox { private TextField textField ; pr..

(Effective Java) 규칙16. public 클래스에서는 public필드가 아닌 접근자 메서드를 사용하라 public 필드의 문제 인스턴스 필드들을 모아놓는 일 외에는 아무 목적도 없는 퇴보한 클래스를 작성하려 할 때가 있다. class Point { public double x; public double y; } 이런 클래스는 데이터필드에 직접 접근할 수 있으니 캡슐화의 이점을 제공하지 못함 API를 수정하지 않고는 내부 표현을 바꿀 수 없고, 불변식을 보장할 수 없음 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없음 접근자 메서드 public 클래스에서라면 아래의 방식이 확실히 맞다. class Point { private double x; private double y; public..

규칙9. try-finally보다는 try-with-resources를 사용하라 자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원이 많다. 예) InputStream, OutputStream, java.sql.Connection 등 자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 성능 문제로 이어지기도 한다. finalizer의 문제 전통적으로 자원이 제대로 닫힘을 보장하는 수단으로 try-finally가 쓰였다. static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLi..

(Effective Java) 규칙12. toString을 항상 재정의하라 toString() java.lang.Object 클래스의 toString 메서드는 일반적으로 사용자가 보려는 문자열이 아니다. 클래스 이름 다음에 @기호와 16진수로 표현된 해시 코드가 붙은 문자열 (예: "PhoneNumber@163b91") toString의 일반 규약을 보게 되면 "사람이 읽기 쉽도록 간략하지만 유용한 정보를 제공해야 한다"라고 되어 있다. PhoneNumber@adbbd 보다는 707-867-5309가 훨씬 유익한 정보를 담고 있는 것처럼 더불어 toString 일반 규약에는 "모든 하위 클래스는 이 메서드를 재정의함이 바람직하다"라는 구절도 있음 toString()을 재정의 해야 하는 이유 toStrin..