일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
29 | 30 | 31 |
- 리얼월드HTTP
- 랜선아미안해
- kotliln
- 워드프레스
- 브로틀리
- 지수반등
- 코드스피츠
- 이렇게살아야되나자괴감이
- cache-control
- Spring
- 알고리즘
- 클래스레벨밸리데이션
- 지뢰찾기
- 개미수열
- brotli
- Kotlin
- i18n
- HTTP
- 알게뭐냐
- jsr380
- etag
- cross parameter
- LastModified
- jsr303
- 스프링
- Today
- Total
목록개발관련 잡다/스터디_세미나이야기 (7)
취미개발 블로그와 마음수양
## 메모리 주소의 별명 Type 데이타 타입에 대한 이야기 형 Types Role : 형을 통해 역할을 묘사함 Responsibility : 형을 통해 로직을 표현 Message : 형을 통해 메시지를 공유 Protocol : 객체간 계약을 형을 통해 공유함 마커인터페이스 : 몸체가 없지만 형.. ## static, enum, class static : 단 한개의 인스턴스가 존재 (동시성 문제를 해결해야 함) enum : 제한된 수의 인스턴스가 존재 (제너릭에 사용불가없음) class : 무제한의 인스턴스 존재 enum 은 JVM이 기술되어있는 인스턴스를 만들고 시작. static 초기화 보다 더 빨리. static 은 factory 이거나 상태갖지 않는 유틸리티 유틸리티 함수와 메서드 구분 this ..
## OOP base system Value & Identifier 값과 식별자 객체지향에서 같은가를 평가 , 메모리 주소가 같은가. 값을 사용한 컨텍스트는 값이 같으면 같다. 어떠한 유형의 언어에서 데이터를 값으로 볼 것인가 객체로 볼 것인가. 값으로볼것인가, 객체로 볼 것인가. 값으로 보면 무슨 객체든 간에 안에 있는 값이 같은지가 평가가 될 것. 식별자를 통해서 걔를 인식하는 것이지. 값을 통해서 값으로 인식하는 것이 아니다. 값으로 비교해서인식하는 것이 아니다. 객체지향은 값 지향을 사용하지 않는다. 식별자 컨텍스트를 통하여 객체의 협력망을 구성한다. 값 지향 - 함수형 시스템 ## 다형성 Polymorphism Substituion : 대체가능성 Internal Identitiy : 내적동질성 ..
코드스피츠 83 #1 코드를 왜 이리 짤까 - motivation - 돈이 덜 드니까, 돈을 버니까 생각의 기저를 이루는 철학(사료의 틀) 토마스 쿤의 과학혁명 철학을 베이스로 하는 윗단계의 프레임. 구현패턴 : 생각하는 코드의 틀 (가치, 원칙, 패턴) 가치와 원칙에서 반복되는 패턴 Xoriented 어떻게 적용하느냐에 따라서 패턴이 달라짐. Relativism : 토마스 쿤(과학 혁명의 구조) Rationalism : 러커토시 임레(수학적 발견의 논리 : 증명과 반박) 난장판 : 파울 파이어아벤트(방법에의 도전)과 그 이후 상대주의, 합리주의 합리주의 - 최적화. 인간성을 말살하고 합리성 상대주의 : 클래스 위에도 있고, 아래도 있고, JVM은 어플리케이션이지만 클래스 기준으로는 부모 기준을 만들때는..
# 메타포 iOS는 장황하다? 자바는 메타포 혼종이었다? PHP는 빠르다. C를 조금 랩핑해서 PHP를 이길려면 인메로리에서 띄우면 될지도.. 톰캣의 JSP이후부터 부를 때 인메모리에서 부르기 때문 PHP는 매번 새로 불러오면서 그런 JSP를 이긴다 PHP를 필적하는 속도를 가진 애는 클래식 ASP 정도..? # 인터페이스 메소드는 무조건 퍼블릭이어야한다는 제약 어쩔 수 없이 추상클래스를 만드는 이유가 이러한 제약조건때문 i를 붙이냐 안 붙이냐 이펙티브 자바에 i 붙이지 마라는 이야기가 나온 이유로 업계에서 사라짐. # implementation 에서 Impl 을 붙이는 경우에서 이것이 잘못된 것인가 h : 잘못되었다고 생각하지 않는다. 씨쁠쁠에서는 메타데이타가 있어야 한다. 요즘은 IDE가 다 확인해주..
전략객체이자 실행객체 전략객체이자 상태객체 전략객체이자 소유객체? 클래스를 함부로 만들면 안된다 클래스를 만들기전에 객체의 수량을 한정지을지 말지 생각을 해야 한다. 오늘 배운 것은 비지터패턴, 컴포지트 패턴 의존성 역전 제어역전
어떤 알고리즘은 이런 식으로 저런식을 짰는데 코드배치를 비슷한 모양으로 함 어떤 곳은 for문, 어떤 곳은 재귀 일관성있는 설계를 위하여 둘다 함수에 담을 수 있다. 학습비용 효과 1) 고인물효과 (조직전체의 폐쇄를 일으킴) 2) 비용이 늘어난다 (시간=비용) 3) 수정, 확장을 시키지 않으려는 탄성이 일어난다. 그 부분을 폐쇄하고 격리하게 된 다음에 다른 코드를 만들게 됨. 고인물 코드를 if 로 격리시키고 나머지에 내 코드를 적게 됨 ==> 제품의 수명이 짧아짐 해마다 차세대..! 멋있는 설계 = 학습비용을 줄이는 설계 하나만 익숙해지면 나머지를 똑같이 적용할 수 있다? 학습해야하는 비용을 최소한 줄이는 것 일관성있는 설계 => 제너릭한 설계, 알고리즘에 제너릭한. 코드의 배치를 할 수 있는 일관성있..
계약 - 전달받은 메시지의 규격 (precondition ) - 사후조건 (postcondition ) - 자기검증? (invariant) 불변식 (invariant) - 메시지와 무관한 객체의 상태 - 일반적으로 필드값의 상태 점검 - DI에게 위임하거나 초기화 할당으로 처리 : 초기화할당은 객체를 만드는 사람의 역량? 그렇기 때문에 DI 코드 이야기 지난 시간에 배웠던 요금제도를 가지고서 이야기를 하기로 함 Plan -> Calculator, Set 가지고 있음 필드에 대해서는 널을 없애기 위해서 엠프티를 가짐. Calculrator calulator = new Calculrator() 사전조건 (precondtion) 일반적으로 validation 메시지로 받는 값을 스스로 검증함 검증이 확정된 형..