2. OOP 학습 방향
0. 목표
→ 기술 역량 목표와 현재 학습 단계
1. 목표, 거시적 관점에서
일반적으로 신입 개발자가 갖추어야 할 기술적 목표는
간단한 Client-Server-DB클라이언트-서버-DB 구조의 서비스를 분석, 설계, 구현, 테스트 할 수 있는 역량을 갖추는 것입니다.
(가능하다면 암호화, 권한 관리, 배포 환경까지 포함하지만, 장애 대응, 로그와 모니터링은 현실적으로 어렵습니다.)
즉, 하나의 Software소프트웨어가 어떻게 만들어지고 운영되는지 전체 흐름을 이해해야 합니다.
신입 개발자는 이 흐름 안에서 Programming프로그래밍 이라는 소프트웨어 개발의 각 단계를 이해하고
그리고 이 이해를 바탕으로 자신이 만든 Project프로젝트 라는 소프트웨어 결과를 Portfolio포트폴리오에 정리해야 합니다.
핵심
신입 개발자의 목표는 문법을 많이 아는 것이 아니라,
간단한 Client-Server-DB 구조의 서비스를 직접 분석하고 완성해 본 경험을 설명할 수 있는 것입니다.
2. 지금까지
Programming Language프로그래밍 언어의 기초 문법 이론은 비교적 순차적으로 각각 학습할 수 있었습니다.
예를 들어 Data Type자료형, Operator연산자, Conditional Statement조건문, Loop반복문, Function함수, Exception Handling예외 처리 같은 내용은, 간단한 문제를 코드로 해결하는 연습 하며 한단계씩 익혀도 충분했습니다.
그리고 간단한 콘솔 프로젝트를 통해 계획, 분석, 설계, 구현 단계를 경험하고,
역할을 나누고 결과물을 공유하는 협업 관점도 함께 익혔습니다.
3. 앞으로 이론 개념은
Object-Oriented Programming객체지향 프로그래밍, Abstraction추상화, SOLID Principle객체 지향 5대 원칙, Event이벤트, Delegate대리자, Design Pattern디자인 패턴 에서 학습 방식이 달라집니다.
이후의 학습은 단순한 순서 학습이 아니라, 서로 연결된 개념을 반복해서 이해하는 Spiral Learning순환 학습이 필요합니다.
예를 들어 Abstraction을 이해해야 Interface인터페이스의 필요성을 이해할 수 있고,
Interface를 이해해야 SOLID Principle 중 DIP의존성 역전 원칙를 이해하기 쉬워집니다.
또한 Event와 Delegate는 단순한 문법이 아니라 객체 간의 Coupling결합도을 낮추는 방식이며,
Observer Pattern옵저버 패턴이나 MVVMModel-View-ViewModel 아키텍처 구조와도 연결됩니다.
따라서 이후의 학습은
단순히 순서대로 외우는 방식만으로는 부족합니다.
전체 구조를 먼저 1회독 이상 하고, 다시 세부 개념으로 돌아가며, 여러 번 반복해서 연결하는 순환 학습이 필요합니다.
기초 문법
↓
순서대로 학습 가능
객체지향 이후
↓
Abstraction → Interface → SOLID Principle → Event / Delegate → Pattern
↑ ↓
└──────────────── 반복해서 다시 이해 ───────────────────┘
4. 앞으로 프로젝트는
단순한 콘솔 프로그램에서 더 확장된 구조로 진행됩니다.
이전 프로젝트에서는
하나의 파일이나 단순한 함수 구조만으로도 프로그램을 만들 수 있었습니다.
하지만 이후 프로젝트에서는 GUI 기반 프로그램이나 Client-Server 구조의 프로그램으로 확장되면
코드의 역할을 나누고, 파일을 분할하며, 시스템과 시스템이 서로 연동되는 전체 구조를 이해해야 합니다.
예를 들어 GUI 프로그램에서는
화면, 데이터, 이벤트 처리, 비즈니스 로직을 한 곳에 모두 작성하면 코드 관리가 어려워집니다.
따라서 Class를 기준으로 파일을 나누고, 각 객체가 맡은 역할을 분리해야 합니다.
또한 Client-Server 구조에서는
Client가 요청을 보내고, Server가 요청을 처리하며, Database가 데이터를 저장하는 흐름을 이해해야 합니다. 이 과정에서 객체지향, Abstraction, Interface, SOLID Principle, Event, Delegate 같은 개념이 실제 프로젝트 구조 안에서 사용됩니다.
즉, 앞으로의 프로젝트 학습은 단순히 코드를 많이 작성하는 것이 아니라,
프로그램(소스 코드)을 역할별로 나누고, 각 부분이 어떻게 연결되는지 이해하는 방향으로 진행해야 합니다.
STEP 1. OOP 등장배경
→ 보편적인 신기술 학습 방법을 이해하고, OOP 기술의 학습에 적용합니다.
지금까지 C, C++, Python을 통해 프로그래밍 1)기초 문법과 2)첫 번째 프로젝트를 진행하며
분석, 설계, 구현의 소프트웨어 개발 흐름에 대한 감을 잡았습니다.
이제부터는 Class클래스를 기반으로 한 OOP객체지향 프로그래밍를 이해하며 GUI그래픽 사용자 인터페이스를 학습합니다.
"보다 효과적인
OOP 학습 방법은 무엇일까요?"
👨💻 기술이란, 기존에 존재한 어떤 문제를 해결하기 위해 등장합니다.
"신기술을 이해하는 가장 효과적인 방법은 기존의 문제점을 먼저 파악하고,
신기술이 그 문제를 어떻게 해결하는지 확인하는 것입니다."
OOP 역시 마찬가지입니다.
기존 개발 방식어었던 Procedural Programming절차 지향 프로그래밍에서 발생할 수 있었던
공용 데이터 문제, 데이터 변경 문제, 코드 관리 문제를 개선하기 위해 등장한 신기술입니다.
Class 의 학습 방향은 단순히 문법을 배우는 것이 아닙니다.
첫 번째 프로젝트에서 사용했던 POP절차 지향 프로그래밍 방식의 개발 과정을 되짚어보고
기존의 POP 개발 방식에서 왜 데이터를 숨겨야 하는지, 왜 데이터 접근을 제한해야 하는지와 같은 를 문제점을 이해합니다.
그러면 OOP 개발 방식에서 Getter와 Setter 또는 Property 와 같은 기술을 통해 해결하는 방법을 이해합니다.
이러한 이해를 Encapsulation과 Information Hiding 기술 용어로 정리해야 합니다.
STEP 2. 클래스와 추상화 이해
→ Class는 현실의 대상을 코드화하고, 역할별로 나누어 관리하기 위한 기본 단위입니다.
A. Class 구현
Python으로 기초 문법만 학습했다면,
이제 Class라는 자료형을, 최대한 많이 구현하는 연습을 시작해야 합니다.
현실에 존재하는 대상은 무한히 많은 특성을 가질 수 있지만, 프로그램은 그 모든 특성이 필요하지 않습니다.
프로그램에 필요한 속성과 기능만 Class라는 단위의 소스 코드로 관리합니다.
(C++에서 Class, Inheritance상속, Virtual Function가상 함수를 학습했다면,
C#에서는 Abstraction을 더 명확한 설계 관점에서 이해해야 합니다.)
B. 현실 대상의 추상화
Class를 사용하기 위해서는 Digitalization디지털화, Coding코드화, Abstraction, Generalization일반화, Document Management 관점을 함께 봐야 합니다.
| 관점 | 의미 |
| Digitalization | 현실의 정보를 컴퓨터가 다룰 수 있는 형태로 바꿉니다. |
| Coding | 선택한 데이터를 코드로 구현합니다. |
| Abstraction | 필요한 특징만 선택해 표현합니다. |
| Generalization | 공통된 구조를 찾아 재사용 가능한 기준으로 만듭니다. |
| Document Management | 코드를 역할별 파일과 Class 단위로 나누어 관리합니다. |
C. 문서 관리 예시
현실의 대상
↓
필요한 정보 선택
↓
디지털 데이터로 표현
↓
소스 코드로 구현
↓
Class로 정리
↓
공통 구조로 일반화이 과정에서 Class는 단순한 문법이 아니라
현실의 대상을 코드로 표현하는 기본 단위가 됩니다.
또한 Class는 소스 코드를 역할별로 나누어 관리하는 문서 단위이기도 합니다.
회원과 관련된 코드는 Member Class에 작성할 수 있습니다.
예약과 관련된 코드는 Reservation Class에 작성할 수 있습니다.
직원과 관련된 코드는 Employee Class에 작성할 수 있습니다.
이렇게 Class를 기준으로 코드를 분리하면 프로그램의 구조를 더 쉽게 이해할 수 있고, 수정과 유지보수도 쉬워집니다.
따라서 이 단계에서는 Class를 단순히 사용하는 법이 아니라, 현실의 대상을 어떻게 코드로 Abstraction하고 그 코드를 어떻게 Class 단위로 나누어 관리할 것인지 학습해야 합니다.
핵심
Class는 객체를 만들기 위한 문법이면서, 동시에 코드를 역할별로 나누어 관리하는 문서 단위입니다.
STEP 3. 다형성과 일반화 이해
→ 파일 분할 구조의 필요성을 이해합니다.
A. 문서 관리 관점에서
A회사, B회사, C회사에 이력서를 작성한다고 가정해봅시다.
공통되는 부분은 하나의 문서로 관리하지만,
각 회사마다 다르게 작성해야 하는 지원동기나 강조 경험은 별도의 문서로 분리해서 관리할 수 있습니다.
B. OOP 관점에서 상속과 일반화는
문서 관리와 비슷한 구조입니다. (개념x)
Class는 소스 코드를 역할별로 나누어 관리하는 문서 단위이고, 문서는 중복되는 부분과 중복되지 않는 부분이 있습니다.
공통으로 사용되는 속성과 기능은 하나의 클래스라는 소스 코드로 만들고,
상황에 따라 달라지는 부분은 기존 클래스를 확장해서 사용하는 개념이 Inheritance입니다.
공통된 속성과 기능을 Parent Class부모 클래스에 두고,
구체적인 기능을 Child Class자식 클래스에서 확장하는 방식입니다.
하지만 Inheritance를 단순히 코드 재사용을 위한 문법으로만 이해하면 부족합니다.
Inheritance의 중요한 목적은 여러 Child Class를 Parent Class 라는 하나의 공통된 기준으로 관리하게 만드는 것입니다.
핵심
Inheritance는 단순히 코드를 물려받는 문법이 아니라, 여러 Class를 공통된 기준으로 묶어 관리하기 위한 구조입니다.
C. Polymorphism 개념 이해
Polymorphism다형성은 같은 기준으로 여러 객체를 다룰 수 있는 객체지향의 중요한 개념입니다.
말 그대로 하나의 형태로 보이지만, 실제 실행 결과는 객체에 따라 달라질 수 있다는 의미입니다.
예를 들어 Animal이라는 Parent Class가 있고, Dog, Cat, Bird라는 Child Class가 있다고 생각해 보겠습니다.
세 Class는 모두 Animal로 다룰 수 있지만, 각 객체가 소리를 내는 방식은 다를 수 있습니다.
D. Polymorphism: Overriding & Overloading
Polymorphism을 이해하려면 Overriding오버라이딩과 Overloading오버로딩을 함께 구분해야 합니다.
두 개념은 이름이 비슷하지만 목적이 다릅니다.
즉, Overriding은 상속 관계에서 동작을 바꾸는 것이고, Overloading은 입력 형태에 따라 메서드를 구분하는 것입니다.
핵심
Polymorphism은 여러 객체를 하나의 기준으로 다루면서,
실제 동작은 객체마다 다르게 실행되도록 만드는 개념입니다.
E. 파일 분할과 문서 관리
Class 연습 단계에서는 하나의 Class를 하나의 파일로 나누어 관리하는 것에 익숙해지는 것이 중요했습니다.
하지만 Inheritance와 Polymorphism을 학습하면 파일 분할의 기준이 더 명확해집니다.
이제 파일은 단순히 코드가 길어서 나누는 것이 아닙니다.
각 Class가 어떤 역할을 맡고 있는지, 어떤 Class가 공통 기준이고, 어떤 Class가 구체적인 구현인지 드러나도록 나누어야 합니다.
| 파일 | 역할 |
| Animal.cs | 공통 기준이 되는 Parent Class를 작성합니다. |
| Dog.cs | Dog 객체의 구체적인 동작을 작성합니다. |
| Cat.cs | Cat 객체의 구체적인 동작을 작성합니다. |
| Bird.cs | Bird 객체의 구체적인 동작을 작성합니다. |
| Program.cs | 객체를 생성하고 공통 기준으로 실행 흐름을 확인합니다. |
Project
├── Animal.cs
├── Dog.cs
├── Cat.cs
├── Bird.cs
└── Program.cs이 구조에서는 각 파일이 하나의 문서처럼 역할을 가집니다.
Animal.cs는 공통 기준을 설명하는 문서이고, Dog.cs와 Cat.cs는 각각의 구체적인 동작을 설명하는 문서가 됩니다.
따라서 Document Management 관점에서 중요한 것은 파일을 많이 나누는 것이 아닙니다.
역할이 다른 코드를 다른 파일로 분리하고, 같은 기준으로 묶이는 코드는 관계가 드러나도록 배치하는 것입니다.
핵심
Inheritance와 Polymorphism을 학습한 뒤에는 파일을 단순히 분리하는 것이 아니라, 공통 기준과 구체적인 구현이 드러나도록 문서 구조를 설계해야 합니다.
STEP 4. 의존성 문제와 SOLID 원칙
→ Class 관계에서 Object 관계로 확장합니다.
A. Class 관계에서 Object 관계로 확장하는 이유
지금까지 학습한
Class, Inheritance, Polymorphism 단계에서는 같은 계열의 객체를
공통 기준으로 묶고, 객체마다 다른 동작을 표현하는 방법을 학습합니다.
예를 들어 Animal을 기준으로 Dog, Cat, Bird를 바라보거나, Member를 기준으로 여러 회원 유형을 나누는 방식입니다.
이 단계에서는 “비슷한 객체들을 어떤 공통 기준으로 묶을 것인가?”가 중요합니다.
하지만 실제 프로그램은 같은 종류의 객체만으로 구성되지 않습니다.
하나의 기능을 만들기 위해 서로 다른 역할을 가진 객체들이 함께 동작합니다.
SOLID 단계에서는 이 개념을 바탕으로, 서로 다른 역할을 가진 객체들이
어떻게 책임을 나누고, 어떻게 느슨하게 연결되어야 하는지 학습합니다.
따라서 SOLID는 단순히 다섯 가지 원칙을 암기하는 내용이 아니라,
객체 간의 관계와 의존성을 설계하는 기준으로 이해해야 합니다.
같은 계열의 객체 이해
↓
Inheritance / Polymorphism
서로 다른 역할의 객체 관계 이해
↓
SOLID Principle이때 중요한 것은 상속 관계가 아니라 객체와 객체 사이의 관계입니다.
어떤 객체가 어떤 객체를 알고 있어야 하는지, 어떤 객체가 어떤 책임을 가져야 하는지, 한 객체가 다른 객체에 너무 강하게 묶여 있지는 않은지를 판단해야 합니다.
핵심
SOLID Principle은 같은 계열의 객체를 묶는 방법이 아니라, 서로 다른 역할을 가진 객체들이 안정적으로 협력하도록 관계를 설계하는 기준입니다.
B. 의존성 문제 파악
의존성 문제
C. SOLID - 객체 지향의 5대 원칙
SOLID는 Object-Oriented Programming 설계에서 자주 사용되는 다섯 가지 원칙입니다.
각 원칙은 Class와 객체가 너무 강하게 묶이지 않도록 역할을 나누고, 변경에 강한 구조를 만들기 위해 사용됩니다.
| 분류 | Eng. | Kor. |
| SRP | Single Responsibility Principle단일 책임 원칙 | 단일 책임 원칙 |
| OCP | Open-Closed Principle개방-폐쇄 원칙 | 개방-폐쇄 원칙 |
| LSP | Liskov Substitution Principle리스코프 치환 원칙 | 리스코프 치환 원칙 |
| ISP | Interface Segregation Principle인터페이스 분리 원칙 | 인터페이스 분리 원칙 |
| DIP | Dependency Inversion Principle | 의존성 역전 원칙 |
Interface와 Abstract Class추상 클래스는 교재의 이론적 학습만으로는 납득하기 어렵습니다.
이들은 Abstraction과 SOLID Principle을 코드에 적용하기 위한 도구입니다.
따라서 Interface와 Abstract Class는 Abstraction, SOLID Principle과 함께 학습해야 합니다.
Abstraction
↓
Interface / Abstract Class
↓
SOLID Principle 적용
↓
변경에 강한 구조핵심
Interface와 Abstract Class는 별도의 암기 항목이 아니라,
Abstraction과 SOLID Principle을 코드로 연결하는 도구입니다.
STEP 5. 대리자 & 이벤트
→ Delegate와 Event를 동작을 추상화하고 객체 간 의존을 줄이는 방법으로 이해합니다.
Delegate와 Event에서는 SOLID Principle 개념을 확장해서 이해할 수 있습니다.
Delegate는 실행할 Method메서드를 대신 참조합니다.
Event는 특정 상황이 발생했을 때 연결된 Method를 실행합니다.
즉, Delegate와 Event는 Action동작을 Abstraction하는 방법입니다.
이 개념은 객체 간의 직접적인 의존을 줄여주며, DIP와 Observer Pattern을 이해하는 데 연결됩니다.
Delegate의 개념 또한 Abstraction과 SOLID Principle 개념을 확장시키는 이론입니다.
| 개념 | 역할 |
| Delegate | 실행할 Method를 직접 호출하지 않고 참조로 연결합니다. |
| Event | 특정 상황이 발생했을 때 연결된 Method를 실행합니다. |
| Observer Pattern | 상태 변화가 발생했을 때 관련 객체에게 알리는 구조입니다. |
# 직접 호출 구조
객체 A ───── 직접 호출 ─────> 객체 B
# Delegate / Event 구조
객체 A ───── Event 발생
↓
연결된 Method 실행
↓
객체 간 직접 의존 감소핵심
Delegate와 Event는 단순한 문법이 아니라, 동작을 분리하고 객체 간 의존을 낮추기 위한 구조입니다.
STEP 6. 이후 확장 학습
→ 객체지향 이후의 개념 확인
현실 대상을 추상화하는 객체의 추상화에서, 사용자에게 필요한 핵심 기능만 보여주는 기능상의 추상화 기반으로 디자인 패턴과 아키텍처 패턴으로 확장합니다.
Object-Oriented Programming, Abstraction, SOLID Principle, Delegate와 Event를 이해하면 다음 기술을 더 자연스럽게 학습할 수 있습니다.
| 확장 학습 | 연결되는 이유 |
| Thread스레드 | 여러 작업을 동시에 처리하는 흐름을 이해할 때 필요합니다. |
| Network네트워크 | Client와 Server가 데이터를 주고받는 구조를 이해할 때 필요합니다. |
| WinForm윈폼 | GUI 기반 프로그램의 화면과 이벤트 처리를 학습할 수 있습니다. |
| WPFWindows Presentation Foundation | 화면, 데이터 바인딩, 역할 분리 구조를 더 깊게 학습할 수 있습니다. |
| MVVM | View와 Logic을 분리하는 구조를 이해할 때 필요합니다. |
특히 WPF와 MVVM은 Object-Oriented Programming, Event, Data Binding데이터 바인딩, Role Separation역할 분리 개념이 함께 사용됩니다.
따라서 앞에서 배운 개념을 반복적으로 복습하며 이해해야 합니다.
기초 문법
↓
OOP
↓
Abstraction
↓
SOLID Principle
↓
Delegate / Event
↓
Thread / Network / WinForm / WPF / MVVM최종 정리
객체지향 이후의 학습은 한 번에 끝나는 것이 아니라, 실제 기술을 배우는 과정에서 계속 이어갑니다.