- ex) 모델하우스
Controller
|
view -- JCheckBox -- Model
- Model: JCheckBox에 대한 정보 저장, 제공
- view: model의 정보를 이용해 화면에 보여줌
- Controller: 이벤트 감지 model에 정보를 변경
- 기존의 모델을 쓰지않고 사용자가 모델을 확장할 때 interface를 구현
- 기존의 뷰를 쓰지않고 사용자가 뷰를 확장할 수 있다
xxx.Render(interface)를 이용해서 확장
- swing은 controller와 view를 합쳐놓았다.
(실제 하나에 클래스안에 내부클래스로 합쳐져있음 xxx.UI)
model은 xxxx.Model
- 데이터 저장 검색을 위한 매커니즘(데이터 구조), Object[]에 대한 래퍼 클랙스
Collection
<<interface>>
| |
Set(보따리) List(CD케이스) Queue Map
<<interface>> <<interface>> 특징: 키, 중복안됨.
특징: 순서가 없다 특징: 순서가 있다. | |
중복 허용X 데이터 중복 허용. Hashtable HashMap
| | |
HashSet ArrayList Vector
- 하나짜리 객체는 Object타입의 객체
- Vector는 동기화 처리가 가능하여 안전성 보장
단점: 리소스를 많이 잡아먹는다. 많이 쓰면 속도가 떨어짐..
동기화: 동시간대에 처리될경우 가장 먼저 실행되는 명령어만 처리하고
나머지는 처리못하게 닫는다.
Vector는 add대신에 addElement를 쓴다.
elements를 사용할경우 리턴형이 열거형인 Enumeraion으로 반환
-> 동기화 처리를 위해 Object[]을 건드리지 않는다.
- 여러클라이언트에 접속이 필요하여 데이터 관리가 중요한경우 vector
- 데이터를 전달하는것이 중요한 경우 List
- 제네릭(콜렉션API)을 이용한 동일한 데이터 타입만 담을경우 사용
데이터의 안정성과, 형변환이 필요없어진다.
다형성이 줄어드는 단점.
- 예외란? 사소한 에러
- 기본적인 예외처리에서 JVM은 예외가 발생할 경우 예외가 발생한 지점에서 예외를 보여주고 강제종료 한다.
예외가 발생할 경우 JVM은 예외 객체를 생성
Java는 프로그램 실행시 발생할수 있는 예외를 클래스로 만들어 놓았다. 70~80개
- try{ }는 예외가 발생하는 코드부분
catch(){ }는 예외가 발생하면 실행되는 부분
- finally{ }예외가 발생하든 안하든 항상 실행되는 부분 ex)리소스 해제 코드
finally가 필요한 이유 return 키워드가 있어도 finally부분을 실행하기 때문에
System.exit();는 finally실행안됨. (JVM강제 종료이기 때문에)
- 사용자가 직접 예외를 만들수 있다. Exception 클래스를 상속 받아서
- throws: 예외를 던질수 있다.
- throw: 예외를 던진다.
- 예외 클래스 구조
Object
|
