승돌 쓰다

코딩클럽 - 현장이지말입니다 3탄

seungdols 2016. 7. 1. 01:30


Seungdols 개발자 일상

온오프믹스 이미지

오늘은 코딩클럽-현장이지말입니다 3탄을 참여하게 되었습니다.
(사실, 이런 저런 강연을 자주 갔는데, 블로그에는 일상이야기를 적지 않아 데이터를 날린 것이 아쉽네요..
지난, 앱인벤터때도 참여를 했었는데 말이죠..)

오늘의 이야기는 아래의 말로 시작합니다.

디자인 패턴 ? 플랫폼 ?

디자인 패턴? 플랫폼? 이란 용어의 말을 아는지가 더 중요합니다. (처음이니까요.) ?

디자인 패턴?

디자인 패턴이란 초기 건축학에서 가져온 개념입니다. ( 끝……이 아닙니다. )
이해가 안되시더라도 디자인 패턴은 그냥, 초고수들이 짜둔 코드라고 이해하시면 됩니다.

초기 프로그래밍 방식은 기계어 - 어셈블리어 - C언어 ( 사실 씨 전에도 여러 언어가 존재…이를테면, B?) 결국, 임베디드 프로그래밍 + 범용 프로그래밍에서 C언어가 독보적이었는데, 다익스트라의 구조화 프로그래밍 선언 이전에는 Goto 문이 난무한 시절이었습니다. (와호장룡처럼 고수들만 존재…)

하지만, 저 같은 쪼렙들이 나타나면서, 소스 코드를 보고 엥?엉? 거리다가 우리 이제 Goto문을 쓰는 스파게티 코드를 지양하고, 구조적으로 프로그래밍을 하자.(고 하면서 원피스 대항해시대 이후가 그려지기 시작합니다.)

우리, 구조적으로만 짜다 보니 아예 실제 존재하는 녀석처럼, 모아서(객체) 만들자라는 의견이 나옵니다. 그것이 바로 객체 지향 프로그래밍(OOP)입니다. 이후 객체 지향 프로그래밍이 나오게 되면서 디자인 패턴/플랫폼의 개념이 나오게 되었다.

플랫폼이란?

세미나때는 제가 이해한 바로는 프레임워크입니다. 강사님께서 플랫폼이라는 용어를 써주셨지만, 쉽게 이해하고자 하신다면, 프레임워크로 이해하시면 됩니다. 사실 둘을 같은 말입니다.

플랫폼은 저의 견해로는 보통 OS적인 시스템적인 플랫폼을 생각하는 경향이 있습니다. 하지만, 따지고 보면, 프레임워크 또한 개발하는 틀, 기틀을 제공한다는 점에서 플랫폼이고, OS 또한 사용한다는 점에서 틀을 제공하므로 플랫폼이 맞습니다만, 혼동의 요지가 있어 프레임워크로 변경합니다.

고로, 플랫폼(프레임워크)는 내가 만들고 싶은 것을 남도 (쉽게) 만들기 좋게 모아 둔 녀석입니다.

이를테면, 종합 공구 상자?

객체 지향의 특징 3가지

추상화

게임의 캐릭터로 이야기 할 수 있습니다. 근접, 원거리,마법형 캐릭터로 세분화 될 수 있으나, 결국 공격, 방어, 스킬에 대한 것으로 추상화 시킬 수 있음.

캡슐화

접근 제한자를 이용해 데이터에 접근하는 것을 보호하고, 중요 데이터들을 캡슐하여 사용자는 이용에 대한 액션만 제공을 받는다.

다형성
사실 설명 하기 굉장히 까다로운 개념입니다. ( 기술적으로 설명 하자면… 아래와 같습니다. ) 단, 이는 정확하지 않은 정보이므로, 키보드에서 가까운 책장을 보시고, 프로그래밍 언어책을 꺼내 보시면 됩니다.

다양한 객체들이 존재 할 시 이 많은 객체들을 어떻게 관리 할지? 또 하나 하나 생성할지?에 대한 논의가 많아집니다. 추상화 작업 후 상속된 클래스들에 대한 무수한 관리에 대한 단점이 존재하게 됩니다. 결국, 최상의 상속 클래스를 통해 자식 클래스를 생성하고, 자식 클래스를 컨트롤 하게 되는 니즈가 필요하게 되어 나타난 개념입니다.

단, 문제점이 생겨납니다. 플랫폼(그냥 데스크탑, 모바일등)이 각기 달라지기 시작함. 실은 Java의 탄생은 임베디드용 소프트웨어 언어였으며, 밥솥을 개발하기 위해 만든 안전한 언어였습니다. (고슬링의 따끈한 밥 철학)
고로, 플랫폼(삼X 밥솥, 엘X 밥솥등)에 무관하게 프로그래밍을 하고 싶은 욕구가 생겨났습니다.

하지만, 자바는 커피 향을 타고, 웹 브라우저…할배인 넷스케이프 개발에 사용되기 시작하게 되는데…
(그렇게 진화를 시작했습니다.)

MVC 모델 프로그래밍

쉽게 설명하자면, 사용자에게 보여지는 영역 따로, 데이터 조작 영역 따로, 요청 받고 응답해는 영역 따로, 개발하자는 소프트웨어 공학 개발 방법론 중 하나이며, 디자인 패턴의 하나입니다.

이후 세미나는 실제 코드를 기반으로 막코딩 VS MVC 모델 프로그래밍을 막 보여주셨습니다. (강사님은 Vi 고수셨다고 합니다. by seungdols.)

이 뒷 이야기는 제가 메모한 부분이며, 이에 대해서는 풀어서 설명하기가 굉장히 어렵습니다.

왜냐하면, 제가 MVC 모델 프로그래밍에 서투릅니다.(고로, 메모를 계속 보고 또 보고….갑자기 2000년 초반으로 가는…)아무튼 아래는 이렇습니다.)

Controller
값을 받는데, 값이 있는지 없는지 체크하는 것을 컨트롤러단에 둔다. ( 개인적인 기준 )

Model
DAO (Data Access Object) : 데이터 베이스에 접근하는 데이터 객체
모델 영역은 두 가지의 역할을 담당한다.

  1. 서버 요청에 대한 컨트롤러에 응답을 전달하는 역할
  2. 서버 요청에 대한 저장장치에 데이터를 저장하는 역할

비즈니스 로직 부분과 객체 지향 부분으로 나뉘어 진다.

비즈니스 로직 = Flow
서비스들 영역에서 가장 많이 사용 하고, 서비스들의 인터페이스를 연동하게 되면 된다.

오브젝트 로직 = 객체 지향 영역

View
실제 서비스를 보여주는 영역을 말하며, 사용자가 직접 보고, 접근하는 영역을 말한다.


그래서 뭐?

막코딩은 개발시 (편함) 단, 유지보수시엔 (나의 피로도 + 야근지수)가 이차함수로 증가합니다.
그래서 MVC 모델 프로그래밍을 해야합니다.

왜냐? 개발시에는 살짝 편하고, 유지보수시에는 ( 저녁이 있는 삶 )을 보장해줍니다.


저는 창문 밖과 가까이에 있습니다. ( 머리만 보입니다. )


반응형