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

 

https://coding-rengar.tistory.com/27

객체지향 프로그래밍 OOP

 

 

객체지향 프로그래밍을 다시 공부한지 벌써 3일 정도 소요가 되었고 지금의 속도로 공부를 한다면 최소 일요일? 정도는 되야

블로그 글을 전부다 작성 할 수 있을 것 같지만 개인 이슈가 생겨

OOP공부 할 시간이 줄어들어 생각보다 더 오랜 시간동안 공부가 진행 될것같다.  

 

우선 지난번에 마무리 하지 못한 캡슐화부터 시작할려고한다.

 

Encapsulation (캡슐화)

객체의 속성(data fields)과 행위(methods)를 하나로 묶고, 실제 구현 내용 일부를 외부에 감추어 은닉한다.

여기서 많은 사람들이 은닉이라는 단어에 속아 캡슐화 = 은닉화 라고 생각 하시는 분들도 있다고 하는데

캡슐화의 특성으로 인해 은닉화가 생기는거지 캡슐화 = 은닉화는 절대 아니다 

 

캡슐화의 은닉화 특성을 이용하여 생각나는게 일단 가장 기본적으로 좀 중요한 정보들을 외부에서 접근을 막을 수 있다는점

그리고 내가 선택을 통해 열어줄 곳들을 열어 줄수있고 

Swift에서는 접근제어 Open - Public - Internal - Fileprivate - Private (왼쪽으로 갈수록 개방적) 제어 할 수 있다.

 

캡슐화는 외부에서 알  필요가 없는 부분을 감춰서 대상을 단순화 하는 추상화의 한 종류 라고 한다. 

그래서 캡슐화가 중요한 이유?는 불안정한 부분(구현)과 안정적인 부분(퍼블릭 인터페이스)을 분리하여 변경의 범위를 통제를 할 수 있다

현재 다니고 있는 회사에서 SDK를 제작하여 배포가능성을 검토 하던 단계중 심플하게 암호화를 하는 부분이 있었는데 여기서 암호화 방식은 외부에의해 변경될 필요가 없으므로 감추는 것이 이에 해당한다고 생각한다. 캡슐화라는 개념 자체가 음.. 코딩을 하면서 당연히 생각 했던 것들이지만 생각하면서 이게 캡슐화다 라고 생각하면서 코딩을 해보니 잘 모르면서 , 그리고 file 확장영역도 잘 모르면서 사용했던 부분도 많았다 내가 했던 실수중 가장 대표적인 실수가 ViewModel Input Output 구조를 만들때 Output의 값을 ViewConctroller 에서 접근 , 제거 가능하게 만들어 안티패턴을 했던 실수가 기억이 난다. 이렇게 기본을 모르면서 구현만을 위해 공부를 하면 나도모르게 안티패턴 , 안좋은 습관들이 많이 들기에 기초는 항상 공부해야한다.

 

이제 OOP 에서 가장 많이 나오는 이야기인 SOLID의 이야기를 해볼려고한다. 

 

SOLID

• SRP Single Responsibility Principle (단일책임 원칙)
  • 하나의 클래스는 하나의 책임만 가져야 한다
• Open / Closed Principle (개방-폐쇄 원칙)
  • 코드는 확장에는 열려있으나 변겨에는 닫혀 있어야 한다
    • 코드를 변경할때는 최대한 좁은범위 , 새로운 기능을 추가할때는 최대한 쉽게
• Liskov Substitution Principle (리스코프 치환 원칙)
  • 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 instance로 바꿀수 있어야 한다
• Interface Segregation Principle (인터페이스 분리 원칙)
  • 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나 보다 낫다
  • 하나의 범용 프로토콜보다 여러개의 프로토콜로 분리시키는게 더 좋다
• Dependency Inversion Principle (의존관계 역전 원칙)
  • 추상화에 의존하고 구체화에 의존하면 안된다

하나씩 순서대로 공부를 해볼려고한다.

 

SRP

하나의 클래스는 하나의 책임만 가져야 한다 

단일의 범위는 매우 상대적인 부분 , Object- C ,  Swift 더 작은단위로 쪼개는 것을 권장함 예시로 TableViewDelegate , TableViewDataSource

그러다 보니 책임과 함께 고려해서 어느정도의 선을 선택하냐가 매우 중요 하다.

여기서 책임이란?

SRP는 변경의 관점에서 분리 되어야함

특정 기능을 변경하기 위해 수정했는데 클래스의 대부분이 수정되지 않았다면

→ 하나의 클래스가 여러 기능을 가지고 있기에 SRP에 맞지않음

특정 기능을 변경하기 위해 수정했는데 여러 클래스가 수정되었다면

→ 하나의 기능이 다른클래스에 연관이 되어있기에 오류임

기본적으로 사용되는 MVC의 문제점

• 원래 Controller 라는 용어는 View와 Model을 이어주는 존재
• 하지만 ViewController는 View를 관리하는 역활을 하고잇음
• 거기에 Model을 처리하는 로직이 추가됨
• 여러 기능을 가지는 SRP 측면에서 모순이 있음

ios 에서 ViewController 가 SRP를 위반 그래서 MVP , MVVM , VIPER등이 나옴

• ViewController을 View로 바라봄

그래서 디자인패턴의 핵심은? 기능의 분리

내가 진행한 리팩토링 방식은 MVVM - C

ViewController - View 관리기능

ViewModel - 비즈니스 로직 관리

Coordinator - View간 화면 전환관리기능

 

오늘은 OOP 의 캡슐화와 , SRP 에 대해 정리를 진행하였다. 

역시 캡슐화 , SRP 조차 내가 쓰고있던 개념이였고 디자인패턴들을 공부하다보면 자연스럽게 접하는 기능이였지만

이게 어떤 원리다 라는 것은 망각하고 그냥 쓰고 있었던 것 같다. 지난번에도 공부를 하면서 느꼈지만 

기능을 쓰고 , 디자인패턴을 구축하고 , 앱을 리팩토링을 하는데 가장 중요한건 원리를 알고 쓰느냐? 모르고 쓰느냐 의 사소한 차이가

완성된 작품의 디테일을 결정하는 것 같다. 항상 꾸준히 원리를 공부하고 기본을 중요시하게 생각하는

개발자가 되기위해 노력하고 내일도 열심히 화이팅 해야겠다!