Object
java.lang- package 이름
패키지 + 클래스 이름 : 공식적인 fullname
어디에 있는 class이다.
system 풀네임도 java.lang.system
extends가 없는 애들은 모두 부모로 java.lang.Object 가진다.
object 메소드
: 1. equals() 2. getClass() 3. hashcode() 4. toString()
5. notify() 6.wait()
-> 뒤에는 thread처리시 필요
obj.(점) 찍으면 다 보임 -> 외우지 않아도 됨
자식은 부모의 메소드를 사용할 수 있음
Person은 Object의 equals() 사용하다
equals = : 똑같은 객체인지 비교시 사용
사용할때는 obj casting해서 사용함
-> object는 모두 사용가능
-> object의 equals사용
-> "다른 객체"
-> 1번지 10번지 비교(홍길동, 20 읽지 않음)
-> 값을 비교(번짓수가 달라서 다른객체라고 판단)
-> Person의 equals를 쓰긴했지만 내용비교를 하지않아서 쓸모없음
-> 부모의 method사용할 수 없을때 : overriding(메소드 오버라이딩)
: 자식이 다시 만드는 것
-> equals override해서 이름,나이 비교하기(참조값 비교x)
-> 이름, 나이비교해서 같으면 같은걸로 보기!
object에 마우스 가져다놓고 두번 클릭, Ctrl키 누르기
this (내 참조값 ) == obj(받아온 파라미터)
같으면 true
-> copy 하기
person에 다시만들기
-> object 전달되는건 p2임
-> person으로 전달받아서 person으로 캐스팅함
String 비교
-> p1의 equals를 불러서 p1이 가지고 있는 메소드(name, age) 부를 수 있음
-> p1의 age
-> p2는 obj 거쳐서 p1이 됨
age (p1 age) == p.age (p2의 age)
-> 문자열 이렇게 비교하면 안됨(string비교는 따로 있음)
-> 우리가 만든 equals가 동작함
obj equals있음(참조값만 비교, 주소만 비교 -> 내용비교 안함)
-> 애초에 객체 비교 불가능
-> 다시 만들어서 ) equals씀
-> @Override
-> 다시씀
받아온 p2person의 정보를 Person으로 casting하고 age, name비교함
equals는 하드코딩하지 않고, 자동완성한다.
지난간 소스코드 남겨두는 건 좋지 않음
해시코드 만들어지는거 신경쓰지 말고 equals에 포커스
-> age, name같은지 체크
age만 체크하면 -> age만 같으면 같은걸로 봐줌
-> 비교할것을 주지않음
-> person과 student비교하고 있음(같을리가 없으니)
getClass 비교함 (클래스를 비교해서 다르면 같을리가 없다)
-> 우리가 짠것(내용비교 objects뒤에)
-> 결론) 코드는 우리가 만들 필요없음
-> 코드는 대부분 자동완성 할 수 있다
-> ★ 개념이 중요 ) object에 있는 것 쓸 수 있는데 대부분 쓸 수 없어서 overriding해서 사용 가능 !
ex03
-> toString : 클래스 이름 @ 참조값
객체는 참조값이다.
-> 같은값
-> 패키지 + class + 참조값 (숫자)
-> 일반적으로는 to String이 자동으로 호출되서 부를 필요가 없음
object의 toString을 써서 이게 나옴
-> 객체의 내용이 보여짐
원래 object의 toString사용할 수 있으나 찍어주는 모양이 조금 불이익해서 @override - toString() 사용함
-> class 이름 + @ + 참조값
객체값 만들고 싶을때 : @override -> system.out으로 찍어버리기 (일반적인 방법)
이름, 나이 찍힘
-> 이클립스 자동완성 : toString형태 (값을 확인하려는 목적 , 형식에 구애받을 필요없음, 값이 잘 들어있는지 확인하는 용도)
-> 실제 개발 완성품 : 실제로 쓰이지 않음
system.out 단한줄도 들어가있으면 안됨!
-> 서버에 찍히는 것(사용자들이 보는건 아님)
-> 객체가 제대로 값이 없는것 같을때 : 확인하는 용도
tostring 쓰고 sysout으로 찍어보고 확인 끝나면 지우기
-> casting해서 쓰기
-> 다시만들어쓰라는것이 목적임
-> 객체비교는 equals 메소드라는 이름을 사용할것(일종의 지시서 같은것)
Abstract
-> 타입이person이라 study는 호출 x
-> 호출이 목적이라 본문X
-> OVERRIDE한 상태 (다시 만든 상태)
--> 여기까지 override 활용한 upcasting 해결방법
-> 실행되지 않아서 본문 x
-> 본문이 없는 메소드 : 추상메소드
-> (일반적) abstract가 pulblic 뒤에들어감
->{} 본문 제거
-> ;(세미콜론) 추가
-> person은 추상클래스가 됨
-> 추상클래스
★ 중요한 특징 3. 추상클래스는 객체를 생성할 수 없다(미완성된 클래스이기 때문이다-> 본문이 없는애가 있다)
-> 일부러 만든 오류
(study 비워있음)
-> 원래 불가
★중요한 특징 4. 추상클래스의 서브 클래스는 "반드시" 추상 오버라이드해야한다
-> study 오버라이드 필수가 아니었지만 이제는 반드시! 추상만!
-> 메소드 완성해서 사용하게 하라
-> 10장에 추상으로 바꿀 수 있는 것? GameUnit
-> 본문이 없음(추상으로 바꿀 수 있음)
-> 클래스 이름 앞 abstract, 메소드 이름 앞 abstract 붙이기
-> 추상이 중요하지 않음(개념만 알기!)
-> 추상 : 정확히 갖추어진 형태가 없다
interface
-> JDK 1.8이후로 가능(현재우리는)
-> 키워드가 없어질 뿐,
-> 일반 필드는 가질 수 없고 final 상수를 가질 수 있음
-> default만 붙였을뿐 일반 메소드처럼 본문이 있다.
-> info(
-> 클래스로 호출해서(static 메소드라고 부름)
-> 추상메소드만 알아도 문제 없음
-> superclass가 obj 이라고 늘 쓰여있음
-> 사실상 같은거 상속이랑
-> interface(Shape)을 supertype으로 두고 Rectangle를 subtype으로 둠
-> 말만 다름
-> 구현
★★ 인터페이스 사용 많이 할 예정임
Layer 화면
persistant layer DB : 거치는 단계가 있음
-> 층별로 가는것(1층-> 2층 .. -> 4층)
-> 중간단계 : Interface많이씀
-> service layer -> interface 문서로 나와있음 .... service(라는 이름을 가진 interface)
-> 구현해야할 메소드 써있음
-> 오류난 이유?
-> 추상메소드 있어서
-> 추상메소드있으면 꼭 만들어야 함 !
-> ctrl + space( getArea())
-> Abstract 추상
-> 너비, 높이 생성자로 받아옴
-> int -> double로 변환(자동변환)
-> 아무것도 없음(최초1회검색해야함)
-> 상수값 선언해 놓은
-> 가져다 쓸 수 있음
사각형 원을 도형 인터페이스 구현체로 만들수있음
- 인터페이스(superclass)
우리가 아는 upcasting 똑같이 저장가능함
-> 가능하지만
Shape 쓸 수 있음 (부모타입으로 자식을 저장할 수 있음)
-> 디폴트 method 호출가능
info2 class로 부르는 static이라 보이지 않음
-> Shape을 적고 부름(interface이지만 class같은 느낌으로 씀)
게시판서비스 : 간단한 CRUD
-> 실제 개발) 만들어져있음
화면 -> DB단
(기본적으로 5개 혼자 만들수 있으면 됨)
- 목록 가져오기
: 게시글
, Int no 번호에 해당하는 것
, int saveBoard(게시글 board)- 저장할 게시글 전달
, int modifyBoard(게시글 board) - 수정
, int deleteBoard(int no) - 삭제할 게시글
-> 하나씩 안에다가 채우면 됨
-> 연습 1번 할것임(8월 중순전 : jdbc 수업할때)
-> final 상수는 원래 있었음
인터페이스는 대부분 추상으로 구성되어있었고,
필요에 의해서 static 메소드 같이 몇가지 추가됨
★ 면접) 자바 버전 물어보기!
ex07_TourGuide
만들 class는 한개 tourguide 만들기
setter를 통해서 필드 예측
- 생성자는 디폴트 타입이라 안만들어도됨
2.setTour - 2개 다 저장할 수 있는 타입 : Tour(부모타입)
-> setter로 받아서
-> 2개받을 수 있음
-> 둘다 저장하려면 부모 타입이 필요(부모 : Tour)
-> 가이드가 맡은 고나광은 tour의 관광이다
-> 캡슐화의 결과(tour가 일을 맡고 tourguide는 호출만 맡음)
-> 인터페이스 만들면 인터페이스 타입을 쓴다
-> 저장할 수 있는것 : 인터페이스 구현체였음
<8/2 자바시험>
- 범위 : ~ 컬랙션 프레임워크까지
클래스에 메소드 본문 비워있음 -> 메소드 본문 채우기(4개만 비움)
10점 -> 4개를 다 채우면 만점, 못 채우면 60점
ex08_SmartPhone
인터페이스는 다중 구현(상속)이 가능함
다중상속의 흉내 낼 수 있음
->smartphone이 가진 4가지 기능 모두 호출하기
-> phone타입인데 computer타입이기도 하다
-> 모두 그냥 부를 수 있음
둘 이상의 타입을 가진 객체들은 호출에 신경써야함
Camera를 상속받는 smartphone으로 바꾸기
Smartphone에서 구현할 필요 x -이미 camera에 넣어서
-> 타입 안맞을때 다운캐스팅하는 방법 !
ex09_Eatable 내용이 없는 인터페이스
-> 생성자로 받아서 내용 채우기
먹을 수 있는 + 음식 = 먹을수있는 음식
-> 구분하는 용도로 interface 활용하는 것
-> 음식이긴 한데 못먹는 음식(eatable없음)
-> 지금 오류가 나는 이유? '반드시' ~해야한다라는 제한조건있었음
-> 인터페이스에는 추상메소드 없음 (이유가 아님)
-> applemango 생성할때, food의 생성자를 반드시 먼저 호출해야함
-> 호출을 안했음
(슈퍼클래스가 디폴트생성자라면 서브클래스도 호출안할 수 있음)
-> 디폴트 생성자가 아니라서 반드시 불러야 함
-> 상속관계의 자식은 반드시 부모가 먼저 호출되어야함
-> Gosu도 마찬가지로함
-> eateveryting, eatpossible은 컴파일 되게
-> 고수는 컴파일 에러
-> 애플망고, 고수 공통 타입 ;ㅣ food
-> 둘다 받을 수 있는 food로 받기
-> foo에다가 toString 만들어 놓아서 가능함
-> 고수에는 없는데 애플망곰에만 있는 타입 : eatable
고수는 eatable로 구성 x -> 오류 남
: inteface에는 이름이 없고, able이 많이 붙음
-> toString 출력 메세지
-> 탱크는 들어갈 수 없음
(같은 게임 유닛임, 같은 타입이어도 분리가 필요할 때가 있음, 구분할 수 있어야 할때 있음)
-> 인터페이스 활용해서 씀
-> bunk를 class로 만들면 안에 bunkable타입으로 만들어놓으면 , 탱크는 들어갈 수 없음
-> interface를 만들어서 타입으로 쓰는 것
-> 다중구현가능(interface여러개 붙여쓸 수 있음)
ex10_Workable
-> food에서 사용하는 타입, walk에서 사용하는 타입이 달라야 함
pet -> toString
workable
workable interface
-> super클래스 pet에 전달
-> 이렇게하면 )날름이도 받을 수 있음
-> 인터페이스 이용해서 객체 구분
컬랙션 프레임워크
배열을 내장하고 있는 클래스를 써서 배열을 쉽게 쓰자
