그렇다더라...

객체지향 개발은 과거엔 재사용에 초점이 맞춰져 있었다면, 지금은 "새로운 니즈(needs)에 대한 확장성 + 대용량 처리에 대한 수용력"을 중요시 여긴다더라.

=> 알림(에러) 없이 훅 가도 괜찮다면 안 써도 된다.

상속과 합성의 차이는 "캡슐화의 파괴-유지", "수직-수평관계", "extend-implement" 등 다양한 이유로 설명이 되지만, 결국 직접 코딩해보며 경험으로 느껴야 할 내용들이다...

구현에서 막히면... 그냥 놀고 먹어서 그런거다.

그 공유된 장소에 다수의 개발자가 코드를 동시에 관리하며, 이는 곧 버전관리가 된다는 말이다. git이 대표적인 예시다.

이게 있으면 xml을 몰라도 java로 xml을 쓸 수 있다. 반대도 가능.

오버라이딩은 재정의, 오버로딩은 확장.

위 예시처럼 삭제될 구 클래스는 이름에 글자 하나(여기선 hello의 'l')을 빼서 뉴 클래스가 컴파일 되는데 문제 없게 한다.

기업 + 우리들 + 시간 + 노력 + J2EE = 기업에서 우리들이 월급을 받기 위해 자바로 만든 프로그램

AP서버는 쉽게 말하면, 그냥 우리가 아는 일반적인 서버다.

하나의 Thread안에 여러개의 Transaction이 존재할 수 있다.

각 방향으로의 통신을 의미한다.

여기저기 기업들이 자주 쓰는 그런 기술인가보다...

조금 특별한 변수다. 변수의 표준화가 목적 중 하나인 것 같다.

이 jar 파일은 여러 파일을 "하나의 파일" 변환한 것이기에 관리가 편하다는 장점이 있다.

살아 있는 상태의 코드?? 같은거 라더라

Bean = 객체 Bean Container = 객체들의 풀(pool)

"통제(락) 없인, 그 어떤 방법으로도 동시접근을 효율적으로 컨트롤 할 수 없기 때문이다" 라던데 상황에 따라 예외는 존재한다(ex: read만 하는 동시접근일경우 락이 필요할까?).

ex) 계좌 '조회' 트랜잭션과, 계좌 '이체' 트랜잭션은 서로 독립적이다. 즉 "두 트랜잭션은 서로 분리 트랜잭션이다,

이런 분리를 AOP 관점의 프로그래밍이라고 할 수 있다.

불고기버거와 치킨버거의 빵 부분은 비슷한 것과 같은 이치다.

분산 트랜잭션의 특징은, "한 쪽이 실패하면 나머지 참여 트랜잭션들 또한 실패처리 되어야 한다"는 점이다. 그렇지 않으면 데이터의 일관성과 원자성을 보장할 수 없다.