Discover us

About us

Projects

Blog

Events

Members

Development Blog

GDGoC CAU 개발자와 디자이너의 작업 과정과
결과물을 공유하는 공간입니다.

어떻게 프로젝트를 시작하게 되었고,
진행하면서 느낀 개발자와 디자이너의
생생한 스토리를 직접 확인해보세요!

Development

1주차 Spring Study

  • #Back-End
  • Jiwoo Park
  • 2023. 11. 7.

1주차 Spring Study


스터디 날짜 및 장소

  • 매주 화요일 9시 ~ 10시 30분
  • 208관 6층 팀플실5
 

스터디 방식

  • 매주 돌아가면서 한 챕터씩 발표하고 교재에 있는 실습들을 병행
  • GDSC 페이지에 스터디 내용을 기록해서 개인적인 사정으로 결석한 사람의 경우 블로그 글 보고 보강
  • AWS 서버를 이용하는 프로젝트가 나오는 6장부터는 방학 때 스터디를 진행할 예정
 

스터디 내용(10/10)

✅ 인텔리제이 설치
✅ 인텔리제이에서 프로젝트 생성
notion image
 
notion image
 
notion image
✅ 깃 연결
✅ 객체지향 프로그래밍(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)은 프로그래밍에서 필요한 데이터를 추상화 시켜 상태와 행위를 가진 객체로 만들고, 객체들간의 상호작용을 통해 로직을 구성하는 프로그래밍 방법
  • 컴퓨터 프로그램을 여러개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있음.
  • 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용
 

객체지향의 특징

  1. 추상화(Abstraction) : 여러 객체들의 공통적인 특징을 도출해내는 것, 현실 객체를 추상화해서 클래스를 구성
notion image
notion image
//---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(); } }
  1. 캡슐화(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() + "살 입니다."); } }
  1. 상속(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("야옹~"); } }
  1. 다형성(Polymorphism) : 하나의 객체가 여러 형태를 가지는 것 → 다형성 : 실세계와 객체 지향을 1:1로 매칭하는 것이 아니라 역할과 구현으로 구분
  • Runtime(dynamic) 다형성 → 오버라이딩(아예 동일한 메서드이나 자식이 이를 개편)
  • Compile time(static) 다형성 → 오버로딩(매개변수 다름 + 함수명 같음)
notion image
자동차가 바뀐다고 운전자가 바꿀 필요 없음 → 운전자가 차를 바꾼다고해서 그 차에 맞는 새로운 운전면허를 따야하는 것이 아님
즉, 운전자는 자동차가 바뀌어도 영향없음
자동차의 역할 각각 인터페이스에 따라 자동차를 구현했기 때문에(=역할에만 의존하기 때문에) 자동차를 무한히 확장 가능
따라서 클라이언트에 영향을 주지 않고, 새로운 기능을 제공할 수 있음.
이렇게 역할과 구현을 분리하는 것이 중요
  • 클라이언트는 대상의 역할(인터페이스)만 알면 됨
  • 클라이언트는 구현 대상의 내부 구조를 몰라도 됨
  • 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않음
  • 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않음
 

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

  • SRP : 단일 책임 원칙(single responsibility principle) → 코드 변경이 있을 때 파급 효과가 적어야함. ex) 기능이 하나 추가될 때 클래스 여러개를 바꿔야는 경우는 SRP를 만족하지않는 코드.
  • OCP : 개방-폐쇄 원칙(Open/Closed principle) → 확장에는 열려있고, 변경에는 닫혀있음. 객체를 직접 수정하지 않고도 변경 사항을 적용할 수 있도록 설계
  • LSP : 리스코 치환 원칙 (Liskov substitution principle)
  • ISP : 인터페이스 분리 원칙 (Interface segregation principle)
  • DIP : 의존관계 역전 원칙 (Dependency inversion principle)