본문 바로가기

분류 전체보기

 (84)
토비의 스프링 3장- 템플릿 템플릿이란 → 성질이 다른 코드 중에서 변경이 거의 일어나지 않으며 일정한 패턴으로 유지되는 특성을 가진 부분을 자유롭게 변경되는 성질을 가진 부분으로부터 독립시켜서 효과적으로 활용할 수 있도록 하는 방법이다. 3.1 기존의 안좋은 코드 예시 3.1.1 예외처리를 해야함 connection에서 쿼리에 실패해도 connection을 close해야함 → 빠르게 자원을 반환하지 않으면 Connection pool의 리소스가 고갈될 수 있음. 문제는 close도 실패할 수 있음(SQLException 발생) 3.2 변하는 것과 변하지 않는 것 예외처리를 하여 괜찮아지긴 했지만, 코드 자체가 너무 복잡함 (try-catch-finally블록이 2중으로 중첩되어 있고, 모든 메서드마다 반복됨). → 이런 코드가 모..
오브젝트 6장 - 메시지와 인터페이스 책임은 메시지 기반( 아마도 다형성으로 서로 다른 객체가 같은 책임을 수행할 수 있을 것) 협력설명하기 위한 좋은 예시: 서버-클라이언트 모델 메시지는 결국 = 퍼블릭 인터페이스 좋은 인터페이스 = 최소한의 인터페이스와 추상적인 인터페이스 디미터의 법칙 = 낯선 자와 이야기하지 말아라. 인접한 이웃 하고만 말하라 부끄럼타는 코드 = 낮은 결합도 묻지 말고 시켜라 = 원칙을 따르면 밀접하게 연관된 정보와 행동을 함께 가지는 객체를 만들 수 있다. 의도를 드러내는 인터페이스 = 의도를 드러내는 선택자 디미터 법칙의 예외들 → 자료구조는 내부를 보여줘야 좋음. 설계는 트레이드 오프. 결합도와 응집도의 충돌 명령-쿼리 분리 원칙 프로시저 - 부수효과를 발생시킬 수 있지만, 반환값이 없다. 함수- 부수효과를 발생..
토비의 스프링 1장 베스트셀러인 이유가 있는 강추책 1.1 초난감 DAO -> 문제점이 많은 DAO클래스를 시작으로 리팩토링하면서 개선해나가는 작업으로 이야기를 풀어나가고 있음 1.2 중복되는 코드 메서드화, 관심사의 분리, 템플릿 메서드, 팩토리 메서드 패턴 소개 1.3 DB와 연결하는 부분을 아예 다른 클래스로 분리, 추상적인 것을 의존하도록 수정 1.4 오브젝트 팩토리 -> 여러가지 DAO를 만들수 있게하고, 제어의 역전 개념 소개(제어권한을 다른 객체에게 위임하는것) 1.5 드디어 스프링을 사용함, 스프링의 용어 설명. ApplicationContext가 어떻게 작동하는지 설명 1.6 싱글톤 레지스트리(싱글톤의 단점을 모두 없앴음), 오브젝트 스코프(기본적으로 싱글톤), stateless의 중요성 1.7 의존관계 주..
오브젝트 5장 책임 할당하기 책임에 초점을 맞춰서 설계할 때 직면하는 가장 큰 어려움은 어떤 객체에게 어떤 책임을 할당할지를 결정하기가 쉽지 않다는 것. 다양한 책임할당방법이 존재. GRASP 패턴이 책임 할당의 어려움을 해결하기 위한 답을 제시해 줄 것이다. 객체에 책임을 할당하는 기본적인 원리를 살펴보자 책임 주도 설계를 향해 데이터보다는 행동을 결정 객체에게 중요한 것은 데이터가 아니라 외부에 제공하는 행동, 객체의 책임을 의미함. 데이터는 객체가 책임을 수행하는 데 필요한 재료를 제공할뿐이다. 데이터 중심의 질문 흐름 '이 객체가 포함해야 하는 데이터가 무엇인가' → '이 객체가 수행해야 하는 책임은 무엇인가' 객체 중심의 질문 흐름 '이 객체가 수행해야 하는 책임은 무엇인가' → '이 책임을 수행하는 데 필요한 데이터는 무..
Spring Framework Overview 원문 스프링 오버뷰 버전 5.3.10 스프링은 자바 엔터프라이즈 애플리케이션을 만들기 쉽게 만든다. 그것은 당신에게 엔터프라이즈 환경에서 자바를 수용하는 모든 것들을 제공한다, 또한 JVM환경의 그루비와 코틀린을 지원한다, 애플리케이션의 니즈에 따라 다양한 종류의 아키텍쳐를 제공하는 유연성과 함께. 스프링 5.1+ 이후로, 스프링은 JDK8이상에서만 지원되며, jdk 11이상의 버전에 대한 지원도 제공한다. JAVA SE 60이 최소한의 버전이지만, 최신버전을 사용하는 것을 추천한다. 스프링은 다양한 범위의 애플리케이션 시나리오를 지원한다. 넓은 엔터프라이즈에서, 애플리케이션은 오래동안 존재해야하며, JDK와 애플리케이션 서버에서 실행되야하며, 그것의 업그레이드 사이클은 개발자의 컨트롤하에 없는(?_)...
오브젝트 4장 - 설계 품질과 트레이드 오프 올바른 객체에게 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동, 객체지향 설계의 핵심이 책임. 책임을 할당하는 작업이 응집도와 결합도 같은 설계 품질과 깊이 연관돼 있다는 것 변경 →비용 훌륭한 설계 → 변경에 드는 비용이 합리적인 선에서 되도록 적절한 비용 안에서쉽게 변경할 수 있는 설계는 응집도가 높고 서로 느슨하게 결합돼 있는 요소로 구성된다. 나쁜 설계와 좋은 설계를 비교하면서 살펴볼 때 효과가 좋다. 책임이 아닌 상태를 표현하는 데이터 중심의 설계를 살펴보고 객체지향적으로 설계한 구조와 어떤 차이점이 있는지 살펴본다. 상태를 분할의 중심축으로 삼는 방법 책임을 분할의 중식축으로 삼는 방법 책임에 맞추면 변경하기 쉽다. 책임은 인터페이스에 속한다. 상태를 객체 분..
3장 - 역할, 책임, 협력 역할, 책임, 협력 ( 객체지향 패러다임의 관점에서 핵심) 애플리케이션의 구현을 위해 어떤 협력이 필요하고, 협력을 위해 어떤 역할과 책임이 필요한지 고민해야한다. 너무 이른 시기에 구현에 초점을 맞추는 것은 변경하기 어렵고 유연하지 못한 코드를 낳는다. 다양한 객체들 사이에 균형 있게 분배되는 것이 일반적 객체가 협력에 참여하기 위해 수행하는 로직은 책임 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할 책임: 협력에 참여하기 위해 객체가 수행하는 행동 책임은 두가지 분류 : 아는 것과 하는것 하는 것 객체를 생성하거나 계산을 수행하는 등의 스스로 하는 것 다른 객체의 행동을 시작시키는 것 다른 객체의 활동을 제어하고 조절하는 것 아는 것 사적인 정보에 관해 아는 것 관련된 객체에 관해..
오브젝트 2장 - 객체지향 설계 영화 예매 시스템으로 예시( 충분히 복잡하다고 생각하자) 내부와 외부를 구분해야하는 이유( 멤버변수를 pirvate으로 선언하는 이유) → 객체에게 자율성을 주기 위해서( 남이 못건드리게 하기 위해서) 내부에서만 접근 가능한 것 = 구현 외부에서 접근 가능한 public = 인터페이스 프로그래머의 역할을 클래스 작성자와 클라이언트 프로그래머로 구분하는 것이 유용 → 클래스 작성자는 새로운 데이터 타입을 추가하고, 클라이언트 프로그래머는 클래스 작성자가 추가한 데이터 타입을 사용 클래스 작성자는 클라이언트 프로그래머에게 필요한 부분만 공개하고 나머지는 꽁꽁 숨겨야 한다. Money 클래스, 돈과 관련된 일을 처리해줌. long과 같은 것을 쓸수도 있었겠지만, 도메인의 의미를 풍부하게 해줌 협력의 관점에서 ..
오브젝트 - 1장 객체, 설계(강추) 우선 이챕터는 이해할 수 없을 가능성이 높음. ( 결론적으로 이해하기 매우 쉬웠음-> 객체지향의 사실과 오해를 읽고 와서 그런건지.. 그런데 확실한 것은 그 책보다는 쉬움) 다른 챕터들의 내용을 축약해놓고, 그 다음에 하나씩하나씩 다음 챕터에서 나아갈 것이기 때문. 이론이 먼저인가? 실무가 먼저인가? 로버트 글래스 → 이론이 먼저인가? 실무가 먼저인가? 어떤 분야를 막론하고 이론을 정립할 수 없는 초기에는 실무가 먼저 급속한 발전을 이룬다. 실무가 어느정도 발전학 ㅗ난 다음에야 비로소 실무의 실용성을 입증할 수 있는 이론이 서서히 그 모습을 갖추고, 그 후에 이론이 실무를 추월하게 된다. 소프트웨어 분야 → 실무가 더 앞서있으며, 실무가 먼저 객체지향 프로그램을 설계하고 유지보수하는데 필요한 원칙과 기법..
리액트 개발 2~3주차 회고 recharts를 사용하여 차트를 그리고 있는데, 백엔드가 준비가 안되어, 테스트용 rest api서버를 만들어서 만들고 있다. dataType, dateType, chartType을 입력받아, 그것에 해당하는 차트를 그려주도록 유연하게 작성하고 있다. 현재는 리소스가 한개인 경우에 대해서만 차트를 그려주고 있지만, 다음주쯤에는 리소스가 여러개인 경우에 대한 차트도 그려줄 예정이다. recharts의 ResponsiveContainer가 작동하지 않는 오류가 있다. 와 같은 차트를 그릴수 있다. 더 복잡한 차트를 그리는 것은 다음주에 하기로 한다.

티스토리툴바