내일배움캠프 16일차 TIL : 객체지향 특강, 유니티 입문 팀 프로젝트 시작

woollim·2024년 10월 15일
0

내일배움캠프TIL

목록 보기
15/36
post-thumbnail

■ 학습 개요

오늘 계획

  • 메모리구조 정리본 복습
  • 유니티 입문 팀프로젝트 회의
  • 첼린지 꾸준 실습(1주차 첫번째)
  • 객체지향 프로그래밍 특강
  • 유니티 팀프로젝트 진행(캐릭터파트)

학습 회고

  • 메모리 구조 TIL을 복습했다. 어제 정리하며 강의 복기를 한 덕분인지 금방 공부했다.
  • 유니티 입문 팀프로젝트에서 캐릭터 담당을 맡기로 했다.(캐릭터 구현, 캐릭터 선택)
    오늘은 캐릭터 프리팹 생성, 각종 컴포넌트 부착(스프라이트 렌더러, 인풋시스템 등등) 이동 구현(AD 좌우, 스페이스 점프) 애니메이터 연결 까지 했다.
  • 객체지향 특강을 들었다. 오늘은 이해를 위해 강의를 따라가기만 했지만 주말엔 직접 실습하며 익혀볼 예정이다. 이론 복습도 좋지만 요즘들어 느끼는게 실습이 더 효과적인 학습인것 같다. 물론 이론 복습도 중요하기 때문에 계속해야 한다. 다만 실습 비중을 늘리는게 좋을듯 하다.
  • 11일차 TIL이 베스트 TIL에 선정 되었다! 기쁘다!😀


■ 객체지향 프로그래밍 특강

객체, 클래스, 인스턴스

  • 이 셋의 차이점 및 특성을 설명 할 줄 알아야 함 (면접때 자주 나오는 질문)

    • 셋을 구별하는 뚜렷한 개념은 없지만 차이를 이해하고 자신만의 정의로 면접관을 설득 시킬 수 있어야 함
  • 개념

    1. 객체(Object) : 단위, 개념. 특정한 기능을 가지고 실체하는 것. 프로그래밍에선 클래스를 기반으로 생성된 실제 데이터로 보기도 함. 클래스라는 설계도를 바탕으로 메모리에 생성된 실체

    2. 클래스(Class) : 문법. 클래스는 설계도 또는 청사진. 객체를 만들기 위한 틀이나 구조를 정의하는 것. 객체가 가져야 할 데이터와 그 데이터를 처리하는 방법을 클래스 안에 정의함

    3. 인스턴스(Instance) : 메모리에 할당 된 객체/클래스. 클래스를 기반으로 생성된 특정 객체.

객체지행 프로그래밍(Object-Oriented Programming, OOP)의 특징

  1. 캡슐화 (Encapsulation)

    • 관련된 데이터와 기능을 하나의 단위로 묶는 것을 의미
    • 클래스를 사용하여 데이터와 해당 데이터를 조작하는 메서드를 함께 캡슐화하여 정보를 은닉하고, 외부에서 직접적인 접근을 제한함으로써 안정성(보안성)과 유지보수성을 높임
  2. 상속 (Inheritance)

    • 상속은 기존의 클래스를 확장하여 새로운 클래스를 만드는 매커니즘
    • 부모 클래스의 특성과 동작을 자식 클래스가 상속 받아 재사용 할 수 있음
    • 코드의 중복을 줄이고, 클래스 간 계층 구조를 구성하여 코드의 구조화와 유지 보수를 용이하게 함
  3. 다형성 (Polymorphism)

    • 다형성은 하나의 인터페이스나 기능을 다양한 방식으로 구현하거나 사용할 수 있는 능력을 의미
    • 하나의 메서드 이름이 다양한 객체에서 다르게 동작할 수 있도록 하는 것으로, 오버로딩과 오버라이딩을 통해 구현
    • 유연하고 확장 가능한 코드 작성을 가능하게 하며, 코드의 가독성과 재사용성을 높임
  4. 추상화 (Abstraction)

    • 추상화는 복잡한 시스템이나 개념을 단순화하여 필요한 기능에 집중하는 것을 의미 함
    • 클래스나 인터페이스를 사용하여 실제 개념을 모델링하고, 필요한 부분에 대한 명세를 정의함
    • 세부 구현 내용을 감추고 핵심 개념에 집중함으로써 코드의 이해와 유지보수를 용이하게 함
  5. 객체 (Object)

    • 객체는 클래스로부터 생성된 실체로, 데이터와 해당 데이터를 조작하는 메서드를 가지고 있음
    • 객체는 상태(데이터)와 행동(메서드)을 가지며, 실제 세계의 개체나 개념을 모델링 함
    • 객체들 간의 상호작용을 통해 프로그램이 동작하고, 모듈화와 재사용성을 높임

SOLID

  • 실제 적용하고 고민할줄 알아야 함
  • 요약
    • S : 클래스는 하나의 책임만 가져야 함
    • O : 기존 코드를 수정하지 않고 확장할 수 있어야 함
    • L : 하위 클래스는 상위 클래스로 치환 가능해야 함
    • I : 인터페이스는 클라이언트에 필요한 기능만 제공해야 함
    • D : 고수준 모듈은 저수준 모듈에 의존하지 않고, 추상화에 의존해야 함
  1. 단일 책임 원칙 (Single Responsibility Principle, SRP)

    • 하나의 클래스는 하나의 책임(책임이라는 것은 변경의 이유)을 가져야 함
    • 클래스는 하나의 기능만 수행해야 하고, 그 기능에만 집중해야 함
    • 여러 가지 역할을 수행하는 클래스를 만들면, 수정할 때 의도하지 않은 오류가 발생할 가능성이 높음
  2. 개방-폐쇄 원칙 (Open-Closed Principle, OCP)

    • 소프트웨어 구성 요소(클래스, 모듈 등)는 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 함
    • 새로운 기능을 추가할 때 기존 코드를 수정하는 대신, 기존 코드를 확장해서 기능을 추가해야 함
    • 기존 기능에 영향을 주지 않으면서 새로운 기능을 쉽게 추가할 수 있음
  3. 리스코프 치환 원칙 (Liskov Substitution Principle, LSP)

    • 하위 클래스는 상위 클래스로 치환할 수 있어야 함
    • 상위 클래스의 객체를 사용하는 프로그램에서, 하위 클래스를 대신 사용해도 프로그램이 정상적으로 작동해야 함
    • 하위 클래스는 상위 클래스의 계약(메서드 및 속성)을 준수해야 함
    • 상위클래스가 할 줄 아는 것은 하위 클래스도 다 할 줄 알아야 함
    • 놀랍게도 실존 인물이셨다...
  4. 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)

    • 클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 함
    • 하나의 거대한 인터페이스를 여러 개의 작은 인터페이스로 나누어, 클라이언트가 자신에게 필요한 기능만 제공하는 인터페이스에 의존하도록 해야 함
    • 인터페이스에 내용이 너무 많으면 불필요한 의존성이 생기고, 불필요한 메서드를 구현해야 할 수 있음
    • 세분화 해서 꼭 필요한 기능들만 쏙쏙 빼서 쓸 수 있는 것
  5. 의존 역전 원칙 (Dependency Inversion Principle, DIP)

    • 상위 모듈은 하위 모듈에 의존해서는 안 됨. 둘 다 추상화에 의존해야 함
    • 구체적인 클래스가 아닌, 인터페이스나 추상 클래스에 의존함으로써 코드가 더 유연해지고, 의존성이 줄어듬
    • 클래스 간 결합도를 낮출 수 있어, 유지 보수가 쉬워짐

○ OOP 목표

  • 의존성을 낮추고 결합도를 낮춘다

  • 객체의 자율성을 높이고 응집도를 높인다

  • 결합도 / 의존도를 낮추는 법!
    -> 책임(=응집도)를 이동시킨다.
    -> 관람객의 책임? 영화관의 책임? 판매원의 책임은 무엇인가

  • 응집도를 높이는 법!
    -> 연관성이 없는 작업은 다른 객체(클래스)에 위임 함
    -> 객체 내부의 상태를 캡슐화 하고 오직 메세지를 통해서만 상호작용 함
    -> 단일 클래스 상속보단 다중 인터페이스 상속(인터페이스 분리 원칙이 생각나네😀)

  • 점선 : 의존관계
  • 실선 : 연관관계
  • 의존 관계를 줄여야 함
  • 주말에 실습하고 내용 추가할 예정!


■ 유니티 입문 팀프로젝트 - 불피하기 1일차

○ 플레이어 캐릭터 프리펩

  • 컴포넌트 추가 (Sprite Renderer, Rigidbody 2D, Box Collider 2D, Player Input, Animator, 스크립트(PlayerInputController, AvoidFireController, AvoidFireMovement, Player)
  • InputSystem은 sendmasage 형식, Actions는 Move(AD좌우이동), Jump(스페이스바 점프) 추가
  • 트러블 슈팅
    • 스크립트를 다 맞게 작성했음에도 캐릭터가 움직이지 않아 당황했다. 스크립트들을 제 점검하다가 Start 함수에서 GetComponent가 되고 있는 클래스들을 확인했다.
      문득 어제 튜터님께 질문했던 내용들중 게임오브젝트에 부착된 컴포넌트들의 메모리 적재 순서를 여쭤본게 생각났다.
      컴포넌트들은 제일 위에있는 것부터 부착된다. 때문에 순서가 잘못되면 아직 메모리에 적재되지도 않은 클래스 객체에 접근하려해서 작동이 안된 것이다.
      컴포넌트 순서도 바꾸고 GetComponent는 Awake 함수로 옮겼다.😥
  • 점프와 움직임 속도를 테스트하며 바꿔야할 듯 하다. 캐릭터 스탯 클래스를 따로 빼두어 speed를 관리해보면 좋을듯 하다

0개의 댓글