실제 분야에서는 공간복잡도가 중요한 경우가 다수있다.
자바는 타입을 항상 앞에 둔다.
String[] cars;
배열 2가지 타입
- primitive: 숫자 단위 논리 8개
- reference: 위의 8개의 제외한 나머지들, class, intereface, enum, [ ]
배열자체가 reference데이터고 instance(객체)영역에 있다. (이름 옆에 값이 못온다.)
package array;
public class Test {
public static void main(String[] args) {
// 배열도 참조 데이터 형태이다.
// 선언 = 생성 {초기화}
String[] cars = {"Volvo", "BMW", "Ford", "Mazda"}; //할당 연산자가 없어 이름만 저장
System.out.println(cars);
cars[0]="100";
for(int i = 0; i < cars.length;i++) {
System.out.println(cars[i]);
}
}
}
다차원 배열
package array;
public class MultiTest {
public static void main(String[] args) {
// int [][]arr; //선언
// arr=new int[4][3]; //생성
// int [][]arr=new int[4][3]; //생성
// arr[0][0]=100;
int [][] arr= {{1,2,3,4},{5,6,7}};
System.out.println(arr[1][2]);
}
}
package inheritance;
public class Printer {
public void print(Object o) {
if (o instanceof Circle) {
Circle c = (Circle) o;
c.areaCircle();
} else if (o instanceof Rectangle) {
Rectangle r = (Rectangle) o;
r.areaRec();
} else if (o instanceof Triangle) {
Triangle t = (Triangle) o;
t.areaTri();
}
}
}
if 1. 조건
instanceof 2. 타입 체킹
(Circle) 3. 타입 캐스팅
1. 조건
2. 타입 체킹
3. 타입 캐스팅
=> 성능 악성 3대 코드 (성능 ⬇️, 확장성 ⬆️)
package inheritance;
public class Circle extends Shape {
int radius = 4;
@Override
public void area() {
System.out.println("원의 넓이는 "+Math. PI*radius*radius);
}
}
overriding시 성능 향상.. 왜?if x, 체크x, 캐스트,x
이걸 안하려고 사용하는 것
1. 클래스 (Class)
클래스는 객체를 만들기 위한 틀!
Bird 🕊️ , Human🧑🏻🦰, Superman 🦹🏻같은 것들이 클래스로 정의된 객체들
각 클래스는 특정한 속성(필드)과 행동(메소드)을 가지고 있다.
public class Bird extends Animal implements Flyer {
@Override
public void eat() {
System.out.println("벌레를 먹는다...");
}
public void fly() {
System.out.println("날개를 펄럭이며 난다...");
}
}
Bird는 Animal을 상속받고 Flyer 인터페이스를 구현한 클래스이다.
Bird는 eat()이라는 메소드를 구현했다. 이런 형태가 클래스이다.
2. 추상 클래스( Abstract Class)
추상 클래스는 일부 메소드가 구현되지 않은 클래스
이 클래스 자체로는 객체만들 수 없고 이를 상속한 다른 클래스에서 메소드를 구현해야한다.
Animal 클래스가 추상 클래스이다.
public abstract class Animal {
public abstract void eat(); // 이 메소드는 자식 클래스에서 구현해야 함
}
Animal 클래스는 eat()클래스를 추상 메소드로 선언했다. 그래서 Animal을 상속받은 클래스는 반드시 eat() 메서드로 구현해야한다.
3. 인터페이스 (Interface)
구현해야할 메소드의 목록을 정의하는 일종의 계약서,
다중 상속을 위한 프로그램 단위,
모든 메소드가 abstract, 객체의 타입으로 사용,
스스로 객체 생성 불가, more OOP
클래스가 인터페이스를 구현하면, 그 인터페이스에 정의된 메소드들을 반드시 구현해야한다.
Flyer 이라는 인터페이스를 사용한다.
public interface Flyer {
void fly(); // 인터페이스에선 메소드만 선언하고, 구현은 클래스에서 해야 함
}
4. 상속 (Inheritance)
하나의 클래스가 다른 클래스를 확장하여 속성이나 기능을 물려받는 개념
유산 + 타입 확장 + 변경 가능
public class Bird extends Animal {
// Animal 클래스를 상속받아 eat() 메소드를 구현함
}
Bird는 Animal을 상속받아서 Animal이 가지고 있는 기본적인 특성을 그대로 물려받고, eat() 메소드를 구체적으로 구현했다.
이 덕분에 Bird는 Animal의 모든 특성을 가지면서 자신만의 특성을 추가할 수 있다.
5. 메소드 오버라이딩 (Method Overriding)
자식 클래스에서 부모 클래스의 메소드를 재정의(오버라이딩)하는것
public class Bird extends Animal {
@Override
public void eat() {
System.out.println("벌레를 먹는다...");
}
}
Bird 클래스는 Animal 클래스에서 상속받은 eat() 메소드를 재정의해서 자신의 방식으로 구현한것
shadow effect 예외의 이름: override? 이게 맞나?
[URECA] DAY 10 | 자바(2) — console.log("CAPABLE");
[URECA] DAY 10 | 자바(2)
자바에서는 ;(세미콜론) 완전 필수에러 메시지는 많이 읽어보는게 좋다. package com.ysh.basic; import java.sql.Date; public class MyProfile{ public static void main(String[] args ) { int age = 30; double tall = 160.5; char gender =
recordoftheday.tistory.com
OOP 3대 concept 中 (3) polymorphism(다형성)
1) polymorphic variable(다형적 변수) : 슈퍼 타입으로 선언된 변수
==> shadow effect가 생김 (슈퍼 타입 아래의 멤버들이 가려지는 효과)
2) overriding (재정의) : 슈퍼의 메소드를 자식 클래스에서 내용을 변경하여 정의하는 것
==> 확장성, 성능, 정합성 향상
==> shadow effect가 적용되는 않는 예외 메소드
super : public void area () {xxx}
^|| || || ||
sub : public void area () {yyy}
3) overloading : 한 클래스 내에서 같은 이름의 메소드가 다수 존재하는 것
ex) PrintStream의 println 다수
규칙) 메소드 이름은 같고, 파라미터 리스트 반드시 달라야 함.
Modifier
1) Access Modifier
private < (default) < protected < public
class : public, (default)
method,data : 4가지 중 하나
2) Usage Modifier (사용 지정자)
i) static - 객체 생성 없이 사용하라
class : inner class에만 선언
data : 공유하는 데이터
method : 객체 생성 없이 호출 가능한 메소드
ii) abstract - 상속으로만 사용하라 (객체 생성 불가)
class : 객체 생성 불가 클래스
data : x
method : 구현 블락 없음. overriding을 강제
iii) final - 변경없이 사용하라 (지양하자)
class : 상속 불가
data : 상수
method : overriding 불가라는 뜻
more oop 하게 되려면 어떻게 해야할까?
1. new 사용
2. 상속 extends 사용
정답: 2번!
그룹스터디 활동 내용 정리 - 도서관 UML로 정했다.
인터페이스 밑에 클래스가 있다.
인터페이스 책 안에 어떤 메서드가 있을것이냐?
메서드는 기능 위주
만일 책은 어떤 기능이 있을 것이냐?
동사 형태로 메서드를 짓는게 좋다. ex) 책의 유무를 체크하다. 책 고유 번호를 입력하다.
카테고리 유효번호를 세팅
오버라이딩을 할때 인터페이스
모든 메서드가 스트랙(?)이어야 한다?
abstract 클래스에 책
하나하나 클래스를 만들면 확장성이 나쁘다.
소설이라고 하는 하는 애를 추상클래스로 만들었다고 하면?
상속받는 클래스로는 그냥 클래스 소설이 되게 한다.
소설책이 데이터가 된다.
정답이 없다.
요구사항이 명확하지 않기에 어려운것이다.
요구사항안에서 제한을 받는다.
에이블? 그런것들을 고민하자
읽을 수 있는
오디오로 나올 수 있는
보이스 오버 기능에 대해서?
위에와 같은 것들이 인터페이슬 활용가능
책이라고 하는것을 인터페이스로 둬도되는데
~하는 것이라고 고민을 해보자!
정말 관계가 없는 것들이 묶어보는 것이 인터페이스 활용 굳
마이크 모니터 거울 핸드폰
서로 단독적인 특성들
블랙 컬러가 공통점
그러면 블랙이 인터페이스이다.
블랙컬러를 가진것들을 배열로 만들고 싶다. 그러면 블랙의 타입을 검정애들만 올 수 잇게
인터페이스를 전혀 서로 관계가 없는 것들끼리 묶어보자!
💭 정신차리고 수업 듣자
💭 정신줄 한번 놓으면 따라가기 힘들...
💭 오늘은 월요일이니까..
💭 급하게 생각하지말자
💭 하나하나 해보자~
🎵 좋지 아니한가 - 유다빈 밴드
'💡 URECA' 카테고리의 다른 글
[URECA] Day 13 | 자바(5) | 컬렉션 API(ArrayList, HashSet, TreeSet, HashMap) 재귀 (0) | 2025.02.12 |
---|---|
[URECA] DAY 12 | 자바(4) (1) | 2025.02.11 |
[URECA] DAY 10 | 자바(2) (1) | 2025.02.07 |
[URECA] Day09 | 자바(1) (5) | 2025.02.06 |
[URECA] DAY08 | TS(2) (0) | 2025.02.05 |