일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 스프링부트 도커
- jpa lazy
- IOC
- kotlin ::
- 스프링
- spring formatter
- fetch join
- 스프링 포매터
- 동적파라미터
- 비기능적 요구사항
- 기능적 요구사항
- method refetence
- kotlin 리팩터링
- 스프링 시큐리티 설정
- open-session-in-view
- 토비의 스프링
- 스프링di
- ioc컨테이너
- 그래프큐엘
- jpa no session
- 도커 이미지 빌드
- 수정자주입
- 스프링시큐리티
- Spring
- Atomicity
- java predicate
- 소프트웨어의 품격
- 정적팩토리메서드
- 자바 필터
- 생성자주입
- Today
- Total
목록Computer Science/OOP (2)
공부기록
기억해야 할 만한기억해야 할 만한 글귀들을 적는 공간입니다. 개인적으로 이해하기 쉽게 바꾼 말도 있으니, 맥락만 봐주시길 바랍니다. 문서의 변경이 있을 수 있습니다. 모든 소프트웨어 모듈에는 세 가지 목적이 있다. 실행 중에 제대로 동작하는 것. 이것은 모듈의 존재 이유다. 변경을 위해 존재한다. 대부분 모듈은 생명주기 동안 변경되기 때문에 간단한 작업만으로도 변경이 가능해야 한다. 코드를 읽는 사람과 의사소통하는 것이다. 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 한다. 프로그래밍 패러다임의 공존. - 절차형 패러다임과 객체지향 패러다임은 공존할 수 없는가? 예를 들어 절차형 패러다임 과 객체지향 패러다임 이 공존할 수는 없는 걸까? 서로 다른 패러다임이 하나의 언어 안에서 공존함으로써 ..
로버트마틴 기계가 이해하는 코드는 누구나 작성할 수 있다. 하지만 사람이 이해할 수 있는 코드는 잘 훈련된 엔지니어만이 작성할 수 있다. 돌아가는 코드가 아닌 읽을 수 있는 코드를 작성하자. Why OOP ? Encapsulated! 데이터와 그 데이터를 조작하는 코드의 변경은 외부에 영향을 미치지않는다. 어떻게? 인터페이스를 통해. 프로시져를 실행하는 필요한 만큼만의 데이터를 가지게! 코드를 짤 때 어떻게 짜라? 나 말고 다른 사람이 내 코드를 유지보수한다 그 사람은 내 주소와 얼굴을 알고, 총을 갖고있다. 근데 그 사람은 미친사람이다! 아무리 변경안된다고 클라이언트가 말하더라도 변경되지않는 코드는 없다. OOP로 짜자 객체를 볼 때 데이터를 보지말고, 기능으로볼 것. WriticleService 좋아..