전체 글171 [Java] Effective Java 3/E item 7~9 item 7: 다 쓴 객체는 참조 해제하라 public class Stack { private Object[] stack; private int size = 0; public Stack() { stack = new Object[1000]; } public void push(Object e){ /// 구현 내용 } public Object pop(){ if(size == 0){ throw new EmptyStackException(); } return stack[--size]; } // 기타 구현 내용 } 예를 들어 위와 같이 stack을 구현하였을 때, 내용에서 메모리 누수가 발생하는 곳은 pop() 메소드를 실행시켰을 때, 논리적인 개념으로는 stack의 가장 윗 부분의 객체를 꺼내서 사용했다지만 실제.. TIL/Java 2023. 6. 13. [AWS 2023 Summit] 오픈소스 데이터베이스로 탈 오라클 최근에 AWS 2023 Summit의 2번째 날에 참가할 기회가 있었는데, 이 때 본 내용 중 가장 흥미로웠던 세션에 대해 소개해보고자 한다. 글 자체는 행사(4월 말 경) 끝나고 직후에 거의 작성해놨는데, 정리해서 올리는데 너무 오래 걸렸다...ㅎㅎ 오픈소스 데이터베이스로 탈 오라클 온프레미스로 떠있던 상용 데이터베이스 데이터를 클라우드 데이터베이스로 마이그레이션 이를 진행하기 전까지의 고민에 대한 이야기 데이터 베이스 트렌드 프론트↔서버↔(큐 캐시 메시지) ↔ 데이터 베이스 기존에는 oracle과 같은 RDBMS aws로 마이그레이션 된 경우 dynamo db가 핵심 1.자체 관리형 → AWS 관리형 다른 클라우드와 연계가 쉽다 운영부담 감소 캐시 및 영구 인메모리 데이터를 활용 스케일링 문제 해결 .. TIL/AWS 2023. 6. 12. [Java] Effective Java 3/E item 4~6 item4: 인스턴스화를 막으려거든 private 생성자를 사용해라 정적 멤버만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰는 설계X 하지만 생성자를 명시하지 않으면 자동 생성되기에, private 생성자를 만들어 인스턴스화를 막자 이러한 방법은 상속을 불가능하게 하는 효과도 존재 Plus) 추상 클래스로 만드는 것으로 인스턴스화를 막을 수 없음. 왜냐하면 하위 클래스를 만들어 인스턴스화할 수 있기 때문 + 상속하여 사용하라는 의도로 착각될 수 있음 item5: 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 하나 이상의 자원에 의존하는 클래스를 만들 때, 사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱클톤 방식이 적합하지 않음 인스턴스를 생성할 때 생성자에 필요한 자원을.. TIL/Java 2023. 5. 28. [Java] Effective Java 3/E item 1~3 Item1: 생성자 대신 정적 팩토리 메소드를 고려하라 클래스 인스턴스를 얻는 전통적인 수단는 public 생성자 이와 별도의 수단으로 클래스는 정적 팩토리 메소드를 제공할 수 있음 정적 팩토리 메소드가 public 생성자에 비해 가지는 장단점 장점 이름을 가질 수 있음 Ex) BigInteger(int, int, Random) vs BigInteger.probablePrime 호출될 때마다 인스턴스를 새로 생성하지 않아도 됨 생성 비용이 큰 객체가 자주 요청되는 상황이라면 성능적으로 좋음 반복되는 요청에 같은 객체를 반환하는 식의 정적 팩토리 방식의 클래스는 인스턴스 통제할 수 있음. 이를 통해 클래스를 싱글톤으로 만들 수도, 인스턴스화 불가로 만들 수도 있음 반환 타입의 하위 타입 객체를 반환할 수 .. TIL/Java 2023. 5. 26. 방향과 힘, 벡터가 인생이다. 서론 최근에 개인적인 방황을 시작했다. 어떻게 보면 목표를 잃어버렸다. 학생 때는 어떠한 목표의식에 대한 고민이 없었다. 중간 고사, 기말 고사로 휘몰아치는 와중에 수능과 입시라는 장기적인 목표가 존재하였고, 이러한 목표에 도달했을 때 다음에는 졸업과 취업이라는 다음 단계의 목표를 부여받았다. 정말 대부분의 사람들이 사소한 것은 다르지만 대략적인 틀에서는 동일한 길을 걸었기에 그 과정에서 다른 길로 눈을 돌릴 틈도 그럴 만한 특별한 무언가를 가지고 있지도 않았기에 의심없이 길을 걸어왔다. 그 결과 내가 생각했던 목표인 취업이라는 목표에 도달했을 때, 나는 다음 목표를 잃어버렸다. 이전에는 단순히 직장에서 인정받고 좋은 엔지니어가 되는... 매우 추상적인 다음 목표를 상상했는데, 막상 출발선에 서니 그럼 .. 주저리주저리 2023. 5. 24. 스프링 프록시 팩토리 💡 프록시(Proxy) 란? 클라이언트가 실제 사용하려는 대상인양 요청을 받아 처리하는 역할. 프록시에게 요청을 넘겨받아 최종 처리하는 오브젝트는 타깃(Target). 타깃과 프록시인지 클라이언트가 구별할 수 없어야 하기에 둘은 같은 인터페이스를 확장해야 함. 프록시는 사용 목적에 따라 2가지로 나뉨 부가적인 기능 부여 ⇒ 데코레이터 패턴 접근 제어 ⇒ 프록시 패턴 프록시 패턴 객체 생성은 비용 ⇒ 최소한, 필요 시점까지 미루는게 좋음 타깃에 대한 접근권한 제어 가능 캐싱 프록시의 단점 프록시가 멤버변수로 타깃 오브젝트 가지기에 타깃 오브젝트에 종속적 똑같은 기능 수행하는 프록시라도 여러 타깃에 적용하려면 타깃의 갯수 만큼 프록시 생성해야 하기에 코드 중복 발생 프록시를 사용하지 않는 메소드에도 타깃으로.. TIL/Spring & Spring Batch 2023. 5. 24. Inner Class로 DTO 관리 프로젝트 내 VO 혹은 DTO 패키지 안에 필요할 때마다 Class파일을 생성하면 DTO 파일들이 마구마구 늘어난다. 여기서 파생되는 문제점들은.. 부분적으로 중복되는 파일 갯수 자체가 많아지고 보기에 안좋다. 더 이상 ClassName이 중복되지 않는 DTO를 만들기가 어려워집니다. 필드들이 겹치는 DTO로 대충 Response를 내리다보니 Over-Fetching을 하게됩니다. Inner Class로 DTO를 관리한다면 조금 더 깔끔한 패키지를 만들 수 있고, DTO ClassName을 정하는게 수월해진다. 그래서 Inner Class로 DTO를 관리하는 것이 좋지 않나? 라는 생각으로 이러한 방법을 검토해보았다. 예시 코드 @Getter @NoArgsConstructor(access = Access.. TIL/TIL 2023. 5. 10. [클린 코드] 8장 경계 외부 코드(오픈 소스 등)를 사용하지 않을 수 없음, 있지만 매우 비효율적 => 외부 코드와 우리의 코드를 깔끔하게 통합하기 위한 이야기 외부 코드 사용하기 인터페이스 제공자는 많은 고객을 유치하기 위해 범용성을 추구 인터페이스 사용자는 자신의 서비스에 특화되길 원함 예시로 java.util.Map을 들면 // Sensor 라는 객체를 담는 Map을 만든다면 Map sensors = new HashMap(); 위와 같이 Map 인스턴스를 이곳 저곳에 넘긴다면 Map 인터페이스에 변경이 생길 시 수정할 코드가 많아진다. (현재로선 java.util.Map이 더 이상의 수정이 가해질 것 같지 않은 상태이지만, 이러한 상태에 도달하기 전까지 수정이 있었다는 것을 생각해야할 것) public class Sens.. 독서 기록/클린 코드 2023. 4. 24. [클린 코드] 7장 오류처리 오류코드 보다 예외를 사용해라 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 경우 논리와 오류 처리 코드가 섞이기에 호출자 코드가 복잡해짐 + 호출 즉시 오류 확인해야 함 Try-Catch-Finally 문부터 작성하라 try 블록의 트랜잭션 범위부터 구현하게 되어 범위 내에서의 트랜잭션 본질을 유지하기 쉬워짐 미확인(unchecked) 예외를 사용하라 확인된 예외는 OCP(Open Closed Principle)를 위반 => 하위의 메서드에서 확인된 예외를 던지면 상위의 선언부에 해당 예외를 정의해야 함 즉, 캡슐화가 깨진다. 이로 인해 발생하는 의존성이라는 비용은 이익보다 큰 경우가 대다수이다. 예외에 의미를 제공해라 예외를 던질 때는 전후 상황을 충분히 덧붙여 오류가 발생한 원인과 위치를.. 독서 기록/클린 코드 2023. 4. 23. Lombok @Builder vs @Accessor vs Setter 서론 최근 스프링 개발할 때 Lombok의 @Builder 어노테이션을 많이 쓰고 있는데, 아무리 생각해도 기존의 방식인 get/set 방식이랑 비교해서 너무 편해지고 가독성도 좋기에 분명 성능의 일부를 포기하고 이러한 장점을 얻었을 것이라는 생각이 자연스럽게 들었다. 그렇지만 Setter를 활용하는 것은 코드의 가독성도 해치고 무엇보다 너무 귀찮다. 검색하던 와중 이러한 불편함을 해결하는 @Accessors에 대한 존재도 알 수 있었다. 그래서 @Builder 나 @Accessors 같이 편하게 만들어주는 요소들은 성능의 일부를 포기하는 것이 정말 맞나? 라는 답을 찾기 위해 테스트를 수행하고 결과에 대한 이야기를 하기 전에 @Builder와 @Accessors에 대한 이야기를 먼저 해보고자 한다. @.. TIL/TIL 2023. 4. 21. [마이크로 서비스 패턴] 1장 모놀리식 지옥에서 벗어나라 작은 규모의 소프트웨어에서는 모놀리식이 장점이 많음 개발 편함 쉽게 변경 테스트 용이 배포 용이 업-다운 스케일 용이 서비스가 커지면서, 즉 프로그램 규모가 커질수록 위의 장점은 사라지고 단점들이 많아짐 너무 복잡해서 개발자가 주눅든다 (매우 공감…) 코드 베이스를 이해하기 힘듬 (만악의 근원) 자연스럽게 개발이 더뎌짐 자연스럽게 테스트가 오래걸림 자연스럽게 수정,배포가 어려움 갈수록 한물간 기술 스택에 발목 붙잡히다 아키텍쳐 때문에 어쩔 수 없이 점점 한물간 기술 스택을 쓸 수 밖에 없고, 그 특성상 최신 기술을 사용하고자 전체 모놀리식 어플리케이션을 재작성하는 것은 비용도 비용이고 리스크가 높아 그냥 따라갈 수 밖에없음 💡 == 신한카드의 IT 서비스의 현상황이라고 생각 💡 도입부에서 이미 박수 치고.. 독서 기록/마이크로 서비스 패턴 2023. 4. 20. [클린 코드] 6장 객체와 자료 구조 자료 추상화 // 구체적인 Point 클래스 public class Point{ public double x; public double y; } // 추상적인 Point 클래스 public interface Point{ double getX(); double getY(); double setCartesian(double x, double y); double getR(); } 구체적인 Point 클래스는 구현을 노출한다. 변수를 private으로 하여도 각 값마다 get/set 함수를 제공한다면 구현이 외부로 노출된다. 즉 변수 사이에 함수라는 계층을 넣는다고 구현이 감춰지는 것이 아니다! 구현을 감추기 위해서는 추상화가 필요하고, 그 역할을 해주는 것이 추상 인터페이스이다. 사용자는 추상 인터페이스를 통.. 독서 기록/클린 코드 2023. 1. 25. 이전 1 2 3 4 5 ··· 15 다음 반응형