개체 지향 프로그래밍에 대해 정리합니다.
개체 지향 프로그래밍에 대해 정리합니다.
33 items under this folder.
코드를 짜다보면, 어느새 얽히고 섥혀있는 내 프로젝트를 마주한다. 부지런함이 개발자의 덕목이 아닌가라고 생각될 정도로 항상 깔끔함을 유지하는 것이 참 중요하다는 생각이 들곤한다. 혹은 미래의 나와 과거의 나가 항상 현재에서 싸우는 듯하기도 한다.
특정 모듈이 다른 모듈에 의존하는 정도 커플링이 심해진 코드를 스파게티 코드라 함 살펴봐야 할 것들 왜 결합도가 높아졌는가? 어떻게하면 그 결합도를 낮출 수 있는가? 종류 (강한순서로) 내용결합도 하나의 모듈이 다른 모듈의 내부 동작을 수정하거나 의존하는 상태 다른 모듈의 로컬 데이터의 접근하는 경우 A 모듈의 데이터 생성 방법을 변경하면 B 모듈의 변경이 필요 공통결합도 두 개의 모듈이 같은 전역 변수를 공유하는 상태 외부결합도 두 개의 모듈이 외부에서 도입된 데이터 포맷, 통신 프로토콜, 디바이스 인터페이스를 공유하는 상태 외...
모듈 내부의 요소들이 서로 함께 속해있는 정도 결합도와 반대되는 개념 종류 (강한 순서로) 기능적응집도 모듈 내부의 모든 기능이 단일 목적 수행 모든 경우가 이렇다면 가장 이상적 순차적응집도 모듈내에서의 결과를 다른 활동에서 사용하는 경우 교환적응집도 입력과 출력이 동일하나 다른 기능을 수행하는 활동들을 모음 좋지 않나라고 생각할 수 있으나, 단순히 입출력만 같기 때문에 애매함 절차적응집도 다수의 관련 기능을 가질 때, 모듈 구성 요소들이 그 기능을 순차적으로 수행 시간적응집도 특정 시간에 처리되어야 할 활동들을 한 모듈에서 처리...
어느 집단이든 따라하는 가치가 있다. 가정에도 있고, 학교에도 있고, 직장에도 있다. 우리 프로그래머에게는 코드를 짜는 것이 일이기 때문에, 이 품질을 높이는 것이 가장 중요한 안건이다.
개체 지향 프로그래밍을 배우는데 있어 알아두면 좋은 내용들을 정리해본다.
모든 것을 OO로 해결할 수 있을까? 그것에 대항하는 static에 대해 알아보자. Static Method OO에서는 모든 것이 개체속에 있어왔다. 그렇기 때문에 불편함이 발생했다.
그럼 디자인 패턴이 무엇인지에 대해 알아보자. 디자인 패턴 소개 인간은 패턴 인식에 최적화되어 있다. 프로그래밍 작업에 있어서도 귀납적으로 발견한 어떠한 패턴이 있을 것이다.
디자인 패턴의 가장 첫번째인 싱글톤을 알아보자.
Java에서의 Nested Class를 알아보며, 어떻게 변화해 왔을지 한번 생각해보자. Nested Class 클래스 안에 다른 클래스 Java에서는 둘로 나뉜다.
상속은 간단하게 보면 별 문제 없어보이나, 실무적으로 보았을 때 상당히 까다로운 개념이다.
더 큰 기능을 가진 객체나 클래스를 작은 객체나 클래스로 조합하여 새로운 기능을 만드는 프로그래밍 기법 Composition에는 다음과 같은 주요 개념이 포함됩니다: Has-A 관계: 특정 객체가 다른 객체를 “사용”한다는 의미를 가진다.
상속과 컴포지션. 무엇을 선택할지 어떻게 판단해야 하는가? OO에서 재사용성을 중요시하는 이유 Don’t reinvent the wheel! 바퀴는 이미 동작과 상태가 명확한 물체 설계, 구현, 테스팅까지 모두 마친 물체 이걸 가지고 다른 유용한 물체를 만들자.
다형성은 무엇인가? 왜 중요한가? Polymorphism poly + morph + ism: 다양한 + 변하다 + 상태 = 다양한 형태로 변할 수 있는 능력 많은 사람들이 OOP의 핵심이라 여기는 특징 같은 지시를 내렸는데 다른 종류의 개체가 동작을 달리 하는 것 어떤 함수 구현이 실행될지 실행중에 결정된다.
Early Binding과 Late Binding은 성능에서 어떤 차이가 나는가? 실제로는 어떻게 사용하는가? 알게 모르게 당연하게 사용하고 있는 다형적 메서드는 무엇이 있을까? 이른 바인딩 vs.
추상클래스는 왜 필요할까? 다형성은 멋지고 강력한 개념 OO 4대 특성인 이유 (상속, 캡슐화, 다형성, 추상화) 다형성은 상속에 기반 상속과 다형성은 추상화에 기반 공통된 것을 뽑아내어 일반화된, 범용적인 것으로 적용 여러 클래스에서 공통 분모를 뽑아 부모 클래스로 제작 자식마다 달리 작동하는 구현을 부모의 method signature로 일반화 추상화는 조금더 복잡한 문제를 해결하기 위한 것 새로운 개념은 새로운 문제도 가져온다 추상화는 막강하지만 그로 인해 생각지 못한 문제가 발생 역시 사람은 직접 해보고 당해봐야 답을 찾음 ...
인터페이스는 왜 필요할까? 그리고 무엇일까? Interface의 사전적 의미 inter-(상호간의) + -face(면) = interface 접해있는 두 물체나 공간 사이의 경계 사용자는 스위치를 키는 버튼에 집중 이걸 누르면 어떤 일이 일어날지를 앎 (what) 어떻게 그런일이 일어나는지는 모름 (how) 실제 동작은 구현 공간에서 일어남 배선의 연결 사용자는 잘 알지 못하는 공간 구현자만 알고 있음 이미 알고 있는 개념 = 함수 함수는 블랙박스임: 호출자는 내부가 어떻게 도는지 이해하려 하지 않는다.
의존성과 결합도에 대한 정확한 의미를 이해해본다. 의존성(Dependency) A 모듈이 동작하려면 B 모듈이 필요한 경우 OO에서 모듈 == 클래스 클래스 A가 클래스 B에 의존 의존성이 있으면 잘못된 OO 설계다? (code smell) 잘못된 말이다.
인터페이스를 사용해야 하는가? 그냥 실질적인 내용이 담긴 구현체를 사용해야 하는가? 모든 것이 인터페이스여야 한다는 주장 다른 클래스의 메서드를 절대로 직접 호출하면 안된다. 모든 것을 인터페이스로 만들어라.
디자인 패턴을 배우기 전에 주의할 점은 무엇인가? 디자인 패턴 공부 시 주의할 점 디자인 패턴을 배웠다고 바로 쓸 생각은 하지 말 것 기본기를 다지는데 집중 내 코드가 어떻게 도는지 이해하기 전까지.
팩토리 메서드는 무엇일까? 무엇이 좋을까? Factory Method 사용할 클래스를 정확히 몰라도 개체 생성을 가능하게 해주는 패턴 public final class Cup { private int sizeMl; private Cup(int sizeMl) { this.sizeMl = sizeMl; } public static Cup createOrNull(CupSize size) { switch (size) { case SMALL: return new Cup(355); case MEDIUM: return new Cup(473); ...
빌더 패턴은 무엇일까? 무엇을 조심해야 할까? 어떤식으로 활용하는 것이 좋을까? Builder 개체의 생성과정을 그 개체의 클래스로부터 분리하는 방법 개체의 부분부분을 만들어 나가다 준비가되면 그제서야 개체를 생성 StringBuilder 단순한 것은 이걸 사용해서 원하는 문자열을 만들 수 있다.
Adapter 패턴으로 알려져있는 Wrapper 패턴에 대해 알아보자. 이름의 문제 GoF: 09.
Proxy 패턴은 뭘까? 서버에서 들었던 것 같은데, 패턴으로는 어떤 의미가 있는지 알아보자.
책임 연쇄 패턴은 무엇일까? 위키에 실린 예시 Chain-of-responsibility pattern @FunctionalInterface public interface Logger { public enum LogLevel { INFO, DEBUG, WARNING, ERROR, FUNCTIONAL_MESSAGE, FUNCTIONAL_ERROR; public static LogLevel[] all() { return values(); } } abstract void message(String msg, LogLevel severity...
Observer 패턴, 많이 들어봤다. GoF의 정의로 알아보자. Observer 관찰자, 감시자 변화가 생기면 알아챈다. 다만 이 관찰자는 여러명일 수 있다.
개체 지향을 얘기하면 꼭 나오는 단어인 예외에 대해서 알아본다. Exception 사실 예외는 개체지향의 일부가 아니다.
예외 처리를 제대로 하지 못하는 이유는 무엇일까? 예외 처리를 제대로 하지 못하는 이유 과거에 주류이던 예외 처리 방식은 지속적으로 작동이 보장되어야 하는 프로그램에 대해 “하드웨어가 멈추는 크래시”가 무서워서 그랬을 수 있다.
그래서 예외는 어떻게 처리하는 것이 좋은걸까? 오류 상황 예외 상황과 오류 상황을 다른 의미로 사용할 것 오류 상황은 error condition을 말함 이 오류 상황을 처리하는 방법 중에 예외가 있음 오류 상황은 예측 가능한 상황을 의미함 프로그램 실행 중에 기본적으로는 일어나지 않음 하지만 일어날 수 있는 일 따라서 이러한 상황을 처리하는 코드는 프로그램 기능의 일부임 프로그래머가 이를 예측하지 못했다면? 버그 오류 상황을 처리하는 4가지 방법 무시 곧바로 크래시 일단은 작동하는데 언젠가는 크래시 안정적이지 못한 상태로 계속 동...
이전글들은 사실 이 원칙을 위해 달려온 것이 아닌가하는 생각이 든다. OOP의 정수로 불리우는 SOLID원칙에 대해서 깊게 알아보고, 실제 iOS Framework의 설계 방향에 대입하면서 보다 찐한 이해를 경험해보자.
SOLID 설계 정신에 대해 알아보자. SOLID 정신으로 이룰 수 있는 것 소프트웨어 설계를 “유연하게” 할 수 있다. 유연한 소프트웨어 설계, 즉 추상적인 설계로 커플링을 제거할 수 있다.
소수설에서 태어난 다양한 주장들에 대해 알아보자. ADT와 PDA, Alan Kay에 대해 알아보자. 지금까지. 주류 OO에 대해 배웠다. 이제는 소수설들이 어떤 것들이 있었는지 알아보자. 취할 것은 취하고, 아닌 것은 아닌 것임을 알기 위해 배운다.
소수설 주창중 하나인 eXtreme Programming에 대해 알아보자.
변수, 클래스, 구조체 등을 선언할 때, 해당 객체 내부에서 사용하는 타입을 고정하지 않고 임의의 타입을 사용할 수 있도록 하는 것 실제 사용하는 시점에 사용하는 타입을 결정한다.