관심사의 분리와 객체지향 그리고 코딩이 어려운 이유(행하는 주체와 그것을 받아오는 대상의 정의의 어려움) [20220709 til]

관심사의 분리 라고 들어보았나?

하나의 관심사가 여기저기 흩어져 있으면 중복되는 코드로 존재하면, 그 관심사에 변경이 일어날 때 엄청난 수정이 발생된다.

먼저, 이는 메소드 추출 리팩토리 기법(extract method)으로 중복된 코드를 하나의 메소드로 정의하여 분리할 수 있다.

 

즉 프로그램을 수정하거나 재접근하거나 차후 리빌딩할때도 관심사의 분리를 무시한 코드는 코드를 식별하기 어려워 엄청난 수정( 즉 노동력 비용 등)이 필요로 하기때문에 필요한 기법이라고 한다.

 

객체 지향 프로그래밍 이란?

객체 지향 프로그래밍  ( Object-Oriented Programming, OOP)은 컴퓨터 프로그래밍의 패러다임 중 하나이다. 객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.

객체 지향 프로그래밍은 프로그램을 유연하고 변경이 쉽게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다. 또한 프로그래밍을 더 배우기 쉽게 하고 소프트웨어 개발과 보수를 간편하게 하며, 보다 직관적인 코드 분석을 가능하게 하는 장점이 있다. 그러나 지나친 프로그램의 객체화 경향은 실제 세계의 모습을 그대로 반영하지 못한다는 비판을 받기도 한다.  

-출처 위키백과

 

즉 코드의 집합체가 아니라 코드들을 하나의 객체 (사물이라고 해도 될듯) 로 보아 각자의 개별적 존재를 파악하고 접근하기 쉽고 수정도 용이해지는 그런 것 같다. ->  처음 듣자마자 그냥 어지러운 방의 정리(어수선한 방 -> 코드의 뭉치들 , 객체지향 -> 분류된 곳들이 명확한 정돈된 방)의 개념이라고 생각했는데 사실 이게 얼마나 중요한지 아직 매우 큰 프로그램을 다뤄보지 않은 나로서는 잘모르겠는데 분명한 건 

매우 매우매무애우매ㅜㅇ매우매우 간단한 허졉같은 프로그램 하나를 간단히 만들어도 코드 몇 백줄은 들어간다는거 ... 그리고 거기엔 영어로 된 메소드와 코드 언어 그리고 우리가 지은 변수명 까지 (근 일주일간 사놓은 요리재료 다 때려넣고 이 안에 무슨 재료 찾는 그런 느낌이려나) ..하면 머리가 팡~ 디스코 팡팡 이 된다.

WTF!?

패키지(Package)

여러분은 아마도 폴더를 이용하여 파일을 정리해 본 경험이 있을것이다. 파일 여러개가 한 폴더에 뒤죽박죽 섞여 있을 때 파일들을 성격에 맞게 분류한 다음 새 폴더에 저장시키는 식으로 말이다.

자바의 패키지도 이것과 완전히 동일한 개념이다. 패키지는 비슷한 성격의 자바 클래스들을 모아 놓은 자바의 디렉토리이다.

 

뭐 패키지도 있어서 분류를 해야하는데 이게 사실 어떤 정보를 어디서 누가 어떻게 받아서 처리하는지에 대한 완벽한 그림이 없으면 ... 분류가 매우 어렵다

 

지금 눈 감고 자신이 있는 방을 떠올려보라 그리고 모든 물건들이 각자 있어야할 위치에 있는가?그리고 있어야할 곳에 있을 물건이 전혀 다른 곳에 있진 않은가?

위와 같은 느낌..그래서 어떤 변수나 객체들을 생성하고 그것을 받아서 다른 메소드들이나 인스턴스 들이 이용하고 하면서 어떤 것이 여기서 어떻게 작용하는지를 알기가 너무 어렵다.. 아무튼 각설하고 오늘은 또 실수를 하나 기록해보려고한다.

 

우선 버튼 액션리스너로(스윙에서) 버튼을 클릭시 다음 정보들을 받아와 transfer메소드 즉 송금이 실행되도록 했다. 우선 송금은 잘된다. 지금은 거래내역을 기록하고싶다.

inputAccountNumber  = 입력한 계좌번호

receiverAccountNumber = 받는 사람 계좌 번호

transferAmount = 보내는 금액

그래서 거래를 처리해주는(사실 거래가 여기서 처리되어야하는지도 의문이다 나만그런지 모르겠는데 어떤클래스에서 어떤행동을 어떻게 정의할거냐에 따라서 매개변수를 다루는 복잡성이 차원이 달라진다.) Account 클래스로 넘어와 transfer메소드의 정의

우선 거래내역을 기록 하기위한 List Transactions 를 하나 만들었다 그리고 송금이 실행될 때마다 기록을 하도록 했다.

문제는 toAccount.getTransactions().add( 기록할 내용)

자꾸 생각이 보내는 쪽에서 (심지어 생각해보니 fromAccount 도 아니었네..)의 거래내역을 불러와 기록해주면 된다는 생각에 잡혀 자꾸 저것의 오류를 전혀 생각하지 못했다.

지금 다시 정리해보면 내가 매개변수의 이름으로 정의해놓은 transfer의 매개변수 이름 toAccount(객체가 될 매개변수 명) 는 결국 타입 Account(클래스)에서 정의되있는걸 참조해서 실체화시키는건데 그걸 다시 class 파일 안에서 to.Account를 넣고 있으니... ( 오 정리하면서 이해됨) 한 마디로 자전거의 특징과 구조들을 정리해놓은 설계도(클래스)에 갑자기 '옆집 영희의 세발자전거 붕붕이(생성한 인스턴스 명)'는 이라는 거의 행동을 정의해놓으니 말이 되는가...

그래서 사실 그땐 멘붕이라 어떡하지 하닥 동료분들의 깃허브가서 참조하니 탁 풀렸다...

그냥..getter가 아닌 List transactions 원본을 가져오면 되는 거... ( 수업때 그리 했는데 ...아휴)

 

무엇이 나를 이토록 헷갈리게 하는가?

 사실 요며칠 자바에서 쓰이는 개념들을 정의와 역할 활용법을 알고난 이후로는 이렇게 무언가 이런 개념들의 역할을 잘못 써서 실수가 나지 않고 이 개념들에 내가 이름 입힌 것들이 나를 매우 헷갈리게한다는 걸 알았다.

프로그래밍에서 네이밍 즉 이름짓기는 단순히 철수가 응남이로 개명하는게 아니라 의미를 지닌다.
이것이 문제다. 
한 번 이름이 지어진 이후로는 나는 그 이름들을 특정기능을 가진 명령어가 아니라 그 이름 자체로 보고 있었다.

즉 이게 무슨 말이냐면 자전거가 뭐냐고 묻고 페달이 뭐냐고 묻는다면 자전거는 사람의 인력과 체인 그리고 바퀴를 이용해서 이동할수 있는 수단 이고 페달은 인력을 전달하기 위한 수단이라고는 아는데 이 개별적 자전거에 철수네 으르렁바이크, 영희네 경주마, 철수의 페라리엔진 

이런식으로 이름을 지어주는 순간부터 이 아이들의 원래 타입( 클래스인지 메소드인지 변수인지 생성된 객체인지,단순 값인건지 등)을 잊어버리는 일이 자주 발생한다는 걸 알았다. 오 쓰고나니 좋다 내가 뭐가 문젠지 파악!

 

ㅈㄹ 중요한 액션플랜!

코드가 논리적으로 구성되었는데도 잘 풀리지 않는다면 내가 사용하고있는 객체들의 타입과 역할로 돌아가 다시 파악해보자.

 

궁금하진 않겠지만 깨알 기록

이렇게 송금을 하면 기록이 잘 된다 이말씀!

그리고 계좌번호가 일치 하지 않으면 송금 안되게 깨알 장난도 쳐놓았다. 뿌듯하다 그래도..(작은거에 행복해 할 줄 알아야 합니다 여러분..)

Yeah~~~~

Oh Yeahhh It is coming,

Yeah~~ I feel it coming!

클럽을 못가면 여기서라도 춤을