GDSC Space

1주차 Spring Study

스터디 날짜 및 장소

매주 화요일 9시 ~ 10시 30분

208관 6층 팀플실5

스터디 방식

매주 돌아가면서 한 챕터씩 발표하고 교재에 있는 실습들을 병행

GDSC 페이지에 스터디 내용을 기록해서 개인적인 사정으로 결석한 사람의 경우 블로그 글 보고 보강

AWS 서버를 이용하는 프로젝트가 나오는 6장부터는 방학 때 스터디를 진행할 예정

스터디 내용(10/10)

✅ 인텔리제이 설치

✅ 인텔리제이에서 프로젝트 생성

✅ 깃 연결

✅ 객체지향 프로그래밍(OOP)

✅ 상태 코드

성공 상태 코드

200 OK: 요청이 성공적으로 처리되었고 적절한 응답을 제공하였다.

201 Created: 요청이 성공적으로 처리되어 새로운 리소스가 생성되었다. (주로 POST)

204 No Content: 요청이 성공적으로 처리되었으나 응답으로 전달할 데이터는 없다. (주로 UPDATE/DELETE)

실패 상태 코드

400 Bad Request: 클라이언트의 요청이 잘못되었거나 유효하지 않음. 보통 요청 데이터의 형식이나 내용이 올바르지 않을 때 나타난다.

403 Forbidden: 클라이언트에 요청한 리소스에 대한 권한이 없을 때 나타난다. 서버가 요청을 이해했으나, 게시물 삭제 요청 등 클라이언트가 해당 리소스에 접근할 권한이 있어야만 할 때 사용한다.

404 Not Found: 요청한 리소스를 서버에서 찾을 수 없음을 나타내며, 클라이언트가 존재하지 않은 리소스에 접근할 때 발생한다.

405 Method Not Allowed: 클라이언트가 요청한 http 메서드가 해당 리소스에서 허용되지 않음을 의미한다. 예를 들어 GET 요청만 가능한 리소스에 POST 요청을 보낼 때가 해당된다.

409 Conflict: 서버가 요청을 처리하던 중 상태 충돌이 발생했음을 의미한다. 예를 들어 이미 좋아요를 누른 게시물에 다시 좋아요를 누르려 한다거나, 이미 구독을 취소한 태그에 다시 구독을 취소하려는 시도 등이 해당된다.

500 Internal Servor Error: 서버에서 처리 중 예상치 못한 오류가 발생하여 요청을 처리할 수 없는 경우에 나타난다.

객체지향 프로그래밍이란?

객체 지향 프로그래밍 (Object-Oriented Programming, OOP)은 프로그래밍에서 필요한 데이터를 추상화 시켜 상태와 행위를 가진 객체로 만들고, 객체들간의 상호작용을 통해 로직을 구성하는 프로그래밍 방법

컴퓨터 프로그램을 여러개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있음.

프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용

객체지향의 특징

추상화(Abstraction) : 여러 객체들의 공통적인 특징을 도출해내는 것, 현실 객체를 추상화해서 클래스를 구성

캡슐화(Encapsulation) : 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것, 데이터를 직접 노출시키지않고 메서드를 이용해서 보호

상속(Inheritance) : 상위 클래스의 속성을 하위 클래스가 물려받는 것

다형성(Polymorphism) : 하나의 객체가 여러 형태를 가지는 것 → 다형성 : 실세계와 객체 지향을 1:1로 매칭하는 것이 아니라 역할과 구현으로 구분

Runtime(dynamic) 다형성 → 오버라이딩(아예 동일한 메서드이나 자식이 이를 개편)

Compile time(static) 다형성 → 오버로딩(매개변수 다름 + 함수명 같음)

자동차가 바뀐다고 운전자가 바꿀 필요 없음 → 운전자가 차를 바꾼다고해서 그 차에 맞는 새로운 운전면허를 따야하는 것이 아님

즉, 운전자는 자동차가 바뀌어도 영향없음

자동차의 역할 각각 인터페이스에 따라 자동차를 구현했기 때문에(=역할에만 의존하기 때문에) 자동차를 무한히 확장 가능

따라서 클라이언트에 영향을 주지 않고, 새로운 기능을 제공할 수 있음.

이렇게 역할과 구현을 분리하는 것이 중요

클라이언트는 대상의 역할(인터페이스)만 알면 됨

클라이언트는 구현 대상의 내부 구조를 몰라도 됨

클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않음

클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않음

좋은 객체 지향 설계의 5가지 원칙(SOLID)

SRP : 단일 책임 원칙(single responsibility principle) → 코드 변경이 있을 때 파급 효과가 적어야함. ex) 기능이 하나 추가될 때 클래스 여러개를 바꿔야는 경우는 SRP를 만족하지않는 코드.

OCP : 개방-폐쇄 원칙(Open/Closed principle) → 확장에는 열려있고, 변경에는 닫혀있음. 객체를 직접 수정하지 않고도 변경 사항을 적용할 수 있도록 설계

LSP : 리스코 치환 원칙 (Liskov substitution principle)

ISP : 인터페이스 분리 원칙 (Interface segregation principle)

DIP : 의존관계 역전 원칙 (Dependency inversion principle)

1주차 Spring Study

스터디 날짜 및 장소

매주 화요일 9시 ~ 10시 30분

208관 6층 팀플실5

스터디 방식

매주 돌아가면서 한 챕터씩 발표하고 교재에 있는 실습들을 병행

GDSC 페이지에 스터디 내용을 기록해서 개인적인 사정으로 결석한 사람의 경우 블로그 글 보고 보강

AWS 서버를 이용하는 프로젝트가 나오는 6장부터는 방학 때 스터디를 진행할 예정

스터디 내용(10/10)

✅ 인텔리제이 설치

✅ 인텔리제이에서 프로젝트 생성

✅ 깃 연결

✅ 객체지향 프로그래밍(OOP)

✅ 상태 코드

성공 상태 코드

200 OK: 요청이 성공적으로 처리되었고 적절한 응답을 제공하였다.

201 Created: 요청이 성공적으로 처리되어 새로운 리소스가 생성되었다. (주로 POST)

204 No Content: 요청이 성공적으로 처리되었으나 응답으로 전달할 데이터는 없다. (주로 UPDATE/DELETE)

실패 상태 코드

400 Bad Request: 클라이언트의 요청이 잘못되었거나 유효하지 않음. 보통 요청 데이터의 형식이나 내용이 올바르지 않을 때 나타난다.

403 Forbidden: 클라이언트에 요청한 리소스에 대한 권한이 없을 때 나타난다. 서버가 요청을 이해했으나, 게시물 삭제 요청 등 클라이언트가 해당 리소스에 접근할 권한이 있어야만 할 때 사용한다.

404 Not Found: 요청한 리소스를 서버에서 찾을 수 없음을 나타내며, 클라이언트가 존재하지 않은 리소스에 접근할 때 발생한다.

405 Method Not Allowed: 클라이언트가 요청한 http 메서드가 해당 리소스에서 허용되지 않음을 의미한다. 예를 들어 GET 요청만 가능한 리소스에 POST 요청을 보낼 때가 해당된다.

409 Conflict: 서버가 요청을 처리하던 중 상태 충돌이 발생했음을 의미한다. 예를 들어 이미 좋아요를 누른 게시물에 다시 좋아요를 누르려 한다거나, 이미 구독을 취소한 태그에 다시 구독을 취소하려는 시도 등이 해당된다.

500 Internal Servor Error: 서버에서 처리 중 예상치 못한 오류가 발생하여 요청을 처리할 수 없는 경우에 나타난다.

객체지향 프로그래밍이란?

객체 지향 프로그래밍 (Object-Oriented Programming, OOP)은 프로그래밍에서 필요한 데이터를 추상화 시켜 상태와 행위를 가진 객체로 만들고, 객체들간의 상호작용을 통해 로직을 구성하는 프로그래밍 방법

컴퓨터 프로그램을 여러개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있음.

프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용

객체지향의 특징

추상화(Abstraction) : 여러 객체들의 공통적인 특징을 도출해내는 것, 현실 객체를 추상화해서 클래스를 구성


//---Computer.java---
// 추상 클래스
public abstract class  Computer {
	
    // 추상 메서드
	abstract void display();
	abstract void typing();
	
	public void turnOn() {
		System.out.println("전원을 켭니다.");
	}
	
	public void turnOff() {
		System.out.println("전원을 끕니다.");
	}
}


//---DeskTop.java---
public class DeskTop extends Computer{

	@Override
	void display() {
		System.out.println("DeskTop display");
	}

	@Override
	void typing() {
		System.out.println("DeskTop typing");
	}

	@Override
	public void turnOff() {
		System.out.println("Desktop turnoff");
	}
}


//---NoteBook.java---
public abstract class NoteBook extends Computer{
	@Override
	public void typing() {
		System.out.println("NoteBook typing");		
	}
}


public class ComputerTest {

	public static void main(String[] args) {
		Computer computer = new DeskTop();
		computer.display();
		computer.turnOff();
	}
}

캡슐화(Encapsulation) : 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것, 데이터를 직접 노출시키지않고 메서드를 이용해서 보호


public class Person {
	
	private int age; //외부에서의 직접 접근 제한
	
	//age에 데이터를 읽고쓰기위해 Getter와 setter 소드 생성
	public int getAge() {
		return age;
	}
	
	public void setAge(int age) {
		if (age >= 0) {
			this.age = age;			
		}
	}
}


public class HelloWorld {
	public static void main(String[] args) {

		Person p1 = new Person();
		
		p1.setAge(20);
		System.out.println(p1.getAge() + "살 입니다.");
	}
}

상속(Inheritance) : 상위 클래스의 속성을 하위 클래스가 물려받는 것


  // 상속 예시: 동물 클래스와 하위 클래스
  class Animal {
      void defaultSound() {
          System.out.println("소리를 낸다.");
      }
  }

  class Dog extends Animal {
      void makeSound() {
          System.out.println("멍멍!");
      }
  }

  class Cat extends Animal {
      void makeSound() {
          System.out.println("야옹~");
      }
  }

다형성(Polymorphism) : 하나의 객체가 여러 형태를 가지는 것 → 다형성 : 실세계와 객체 지향을 1:1로 매칭하는 것이 아니라 역할과 구현으로 구분

Runtime(dynamic) 다형성 → 오버라이딩(아예 동일한 메서드이나 자식이 이를 개편)

Compile time(static) 다형성 → 오버로딩(매개변수 다름 + 함수명 같음)

자동차가 바뀐다고 운전자가 바꿀 필요 없음 → 운전자가 차를 바꾼다고해서 그 차에 맞는 새로운 운전면허를 따야하는 것이 아님

즉, 운전자는 자동차가 바뀌어도 영향없음

자동차의 역할 각각 인터페이스에 따라 자동차를 구현했기 때문에(=역할에만 의존하기 때문에) 자동차를 무한히 확장 가능

따라서 클라이언트에 영향을 주지 않고, 새로운 기능을 제공할 수 있음.

이렇게 역할과 구현을 분리하는 것이 중요

클라이언트는 대상의 역할(인터페이스)만 알면 됨

클라이언트는 구현 대상의 내부 구조를 몰라도 됨

클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않음

클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않음

좋은 객체 지향 설계의 5가지 원칙(SOLID)

SRP : 단일 책임 원칙(single responsibility principle) → 코드 변경이 있을 때 파급 효과가 적어야함. ex) 기능이 하나 추가될 때 클래스 여러개를 바꿔야는 경우는 SRP를 만족하지않는 코드.

OCP : 개방-폐쇄 원칙(Open/Closed principle) → 확장에는 열려있고, 변경에는 닫혀있음. 객체를 직접 수정하지 않고도 변경 사항을 적용할 수 있도록 설계

LSP : 리스코 치환 원칙 (Liskov substitution principle)

ISP : 인터페이스 분리 원칙 (Interface segregation principle)

DIP : 의존관계 역전 원칙 (Dependency inversion principle)

Discover us

Blog

Development

1주차 Spring Study

1주차 Spring Study

스터디 날짜 및 장소

스터디 방식

스터디 내용(10/10)

객체지향 프로그래밍이란?

객체지향의 특징

좋은 객체 지향 설계의 5가지 원칙(SOLID)

Development

1주차 Spring Study

1주차 Spring Study

스터디 날짜 및 장소

스터디 방식

스터디 내용(10/10)

객체지향 프로그래밍이란?

객체지향의 특징

좋은 객체 지향 설계의 5가지 원칙(SOLID)