🍎 How's the 14th day going?
아 어제 밤에.. 조과제 엄청 했다.. 간만에 .. 실력이 좀 느낌. 구조화에 대해서 좀 더 생각해 볼 수 있는 시간이었다.근데 만들고 보니깐. 너무 스파게티 코드 처럼 접근이 다양하게 이루어지는 게 좀 아쉽다캡슐화 부분에 대해서 좀 많이 못한 거 같다.아쉬운 부분이다. 그리고 개인 공부를 너무 못했네. 아쉽다 많이..어제 늦게 자서 아침에 정신이 없어서 코드카타도 많이 못했네.낼 부터 다시 개인공부 열심히 하면 좋겠다.일단 코드카타부터 내일의 코드카타는 sql 3문제/ 코드 3문제 목표!
🍊코드카타 목록
- 강원도에 위치한 생산공장 목록 출력하기
- 카드 뭉치
💡오늘 정리 목록
- 객체화에 대한 고찰
🚩오늘의 회고
1. 코드카타
1) 강원도에 위치한 생산공장 목록 출력하기
- sql 문제 / 난이도 하
- Like 와 % 사용, Order by에 대한 문제
SELECT FACTORY_ID,FACTORY_NAME,ADDRESS
FROM FOOD_FACTORY
WHERE ADDRESS LIKE '%강원도%'
ORDER BY FACTORY_ID2) 카드 뭉치
- 이건 살짝 큐에 관련 된 문제였던 거 같다.
- 근데 큐 사용하기 싫어서 합병정렬에서 머지부분을 활용해서 만들었다.
- 사실 그냥 어렵지 않아서.. 뭐.. 앞에 나왔던 문제랑 너무 비슷한듯
class Solution {
public String solution(String[] cards1, String[] cards2, String[] goal) {
int l = 0, r = 0, h = 0;
while (l < cards1.length && r < cards2.length && h < goal.length) {
if (goal[h].equals(cards1[l])) {
l += 1;
h += 1;
} else if (goal[h].equals(cards2[r])) {
r += 1;
h += 1;
} else {
return "No";
}
}
;
while (l < cards1.length && h < goal.length) {
if (cards1[l].equals(goal[h])) {
l += 1;
h += 1;
} else {
return "No";
}
}
while (r < cards2.length && h < goal.length) {
if (goal[h].equals(cards2[r])) {
r += 1;
h += 1;
} else {
return "No";
}
}return "Yes";
}
}
2. 객체화에 대한 고찰
1) 발단
- 팀 과제하면서 튜터님에게 디스 당함. 사실 처음 제안하셨을 때 좋지 않은 방향인 건 알았지만, 그냥 팀과제 자체가 뭔가 실력을 평가하기 보다는 다양한 걸 해보는 데 의의가 있다고 생각해서, 그냥 하시라고 했었는데.. 튜터님에게 칼 같이 까였다. 근데 데이터 구조화에서 문제가 발생하는 부분이 가장 컸는데, 잘못된 부분에 대한 설명이 좀 아쉬웠다. 그래도 확장성에 대해서 말씀하신 부분은 맞는 부분이긴 한데,.. 뭐랄까.. 그 클래스에 대한 지적으로는 맞지 않았다고 생각한다. 전체적인 부분에서의 확장성의 문제가 많긴 했지만, 너무 포괄적인 설명이었다고 생각한다. 여튼 그래서 팀원끼리 이제 객체화에 대한 논의를 했다.
2) 전개
- 다들 객체화에 대해서 눈에 불을 켜고 집중하기 시작했다. 이걸 객체화 할까? 저걸 객체화할까? 그리고 튜터님이 지적해서 그 지적당한 부분 만든 분은 의욕이 없어져서, 다른 분이 객체화 얘기하다가 디스플레이에 대한 추상클래스 생성으로 만들어 보자고 하셨다. 그래서 금방 만드신다길래 기대하고 있었는데,,,,,,,, 이게 웬걸.. 반으로 쪼개났다..
더 황당한건 다른 분도 똑같이 생각했다는것.. 솔직히 매우 충격이었다.
객체화는 사실 아직도 어렵고 뭔가 딱 한단어로 표현 할 수 있을 만큼 잘 알지 못하는거 같다. 그래도.. 반으로 나눠 버리는건.. 대체.. 무슨 객체화지 그래도 객체하면 기능별 분리를 한다던가.. 이런게 있어야 한다고 생각해서 당연히..
디스플레이 기능만 구현 되있을 줄 알았는데.. 좀 당황스러우면서도 객체화란 개념이 참 어렵구나 라는걸 다시 느낄 수 있었다. 근데 반으로 쪼갠니깐 당연히.. 저장 담당하는 변수들이 한쪽에만 있었다... 그래서 저기에 대한 접근에 대한 논의를 나누는 중에.. 저장소가 있으면 좋겠다는 말이 나왔다. 사실 여기까진 이해할 수 있었다.. 근데 다들 객체화에.. 너무 눈이 돌아가서.. 하나 할 때마다.. 추가적인 객체화의 얘기가 나왔다..
사실 어떻게 보면 모든걸 객체화하는게 맞을지도 모르겠다. 객체화의 원칙 중에 좀 기억에 남는게 한 단일 책임의 원칙! 하나의 클래스는 하나의 책임을 지어야 한다. 이게 너무 맘에 드는 말이다. 사실 다른 부분은 개방-폐쇄 원칙 말고는 이 스파르타 코딩 과제에서 해볼 일이 없을 거 같다.
여튼 이런 상황에서 뭔가 답이 없어 보여서.. 마음 속으로.. 그냥 내꺼 기능 추가하면서 만들어 놓으면 좋을 거 같다는 생각이 들어서. 내가 객체화를 해야겠다고 다짐했다.
3) 고찰
드디어 객체화를 시작했다. 생각보다 조모임이 (정말 간만에 활기차고 열띈 조모임이었다...) 오래 끝나서 여덟시 반쯤 부터 시작했다. 일단 나는 객체화를 나누는 거라고 생각한다. 단일 책임의 원칙이 가장 인상 깊어서 그런가. 분류해서 나누기로 했다. 일단 큰 틀에서 나누기로 했다. 그리고 일단 메인에는 사실 뭐 없이 메소드만 돌리는 방식이 가장 객체화에 어울리는거 같아서, 메인은 일단 디스플레이 메소드 불러오고, 초기화 한는 것만 딱 담당해주기로 했다. 물론 초기화도 다른 매소드로 만들어서 메인은 불러오기만.. 했다.
그리고 이제 다른 것들을 나눠야 하는데 앞에서 했던 논의 중에 그나마 가장 괜찮았던게 저장소라는 개념이었다. 사실 데이터 서버라는게 존재하거나, 다른 데이터 프로그램이 있는 상황이 아니니 데이터를 담당 하는 곳을 분리하는게 좀 효율적으로 보였다. 그래서 데이터만 저장할 Score 클래스를 하나 만들었다. 만들고 보니 뭔가 저장소에는 .. 출력문하고 입력받고 이런게.. 너무 안 어울리는 느낌이다. 깔끔하게 데이터만 주고 받고 수정하는 느낌으로 구성하고 싶었다. 그래서 일단 먼저 저장된 데이터를 배치할 list를 배치해주고, 추가, 수정, 삭제, 접근 이 4가지 기능만 담당하도록 만들었다.
그리고 이제 모델 student, score, subject 클래스 사실 이런 모델링 클래스도 역시.. 안에 뭐가 난잡하면.. 모델링의 의미가 없어 보였다. 이 모델링이라는게 데이터화 시켰을 때 각각의 데이터를 담당해줄 클래스라고 생각해서,, 진짜 딱 값 저장해줄 변수.. 그리고 접근해줄 getter, setter. 생성자 이 3가지 요소만으로 구성했다. 그러고 보니 남는 메소드들은 다..
그냥 성적/수강색/과목 이렇게 관리 클래스를 만들어서 분리했다. 약간 다루는 데이터를 위주로 불리 해준 느낌이었다.
그리고 화면에 보여줄 인터페이스를 담당할 디스플레이로 분류 했다. 디스플레이는 화면 담당이니깐 화면 선택 기능과 호출 기능만 부여했다. 이렇게 만들고 구상해서 하나씩 틀에 맞춰서 수정했다.다양하게 접근이 일어나서 매번 객체를 생성해서 할 수도 없고, 특히나 자료소는 하나만 있어야 되서 일단 저장소에 대한 접근 방식은 public static 메소드로 사용했다. 메니지먼트도 똑같이 public static 방식을 사용해서 완성.. 하얗게 불태워서 12시 반 쯤 넘어서 끝났던 것 같다.
그래도 하고나니 매우 뿌듯했다.
4) 회고
수정하면서 좀 고민하던 부분이 어떻게 접근할 지에 대한 부분이었다. 클래스로 불류해서 구조화 했는데. 이게 아무래도 데이터 클래스는 모든 곳에서 쓰이는데 하나만 존재해야 하는 경우라서. 싱글톤이 좋았을 거 같은데.. 사실 접근 방법을 이미 다 static 접근하는 방식으로 클래스명.메소드 이런 방식으로 짜버려서 돌릴 수가 없는게 좀 아쉬웠다. 그리고 메니지먼트 관리한는 클래스를 그냥 단순히 무엇을 다룬는지에 대해서 분류 했었는데.. 사실 이 부분은 기능에 맞춰서 검색기능 , 추가기능 이런 식으로 기능 별로 분리 했으면 좋았을 거 같다. 또 하나 아쉬운건 접근하는 거에 대한 방식. 약간 접근하는 메소드가 저장소에도 있고, 다른 메니지먼트에도 있고 좀 주구난방이었다. 이게 클래스가 가지고 있는 변수들이 다양하다 보니 거기에 맞춰서 또 다양하게 접근이 이루어진 방식이 좀 아쉬웠던 것 같다.
뭔가 딱 저장소에는 하나의 방식으로만 접근하도록 하고.. 밖에서 바꿨으면 좋았을 거 같다. 아 그리고 뭔가 조건에 대한 부분을 확인해주는 메소드도 또 따로 구성했으면 좀 더 접근하기 좋았을 거 같다. 팀원 중에 한 분이 어떤 메소드가 있는지 잘 파악 못하는 모습에서.. 음 구조화에 대한 아쉬움을 많이 느꼈다. 그리고 내가 아예 고려하지 않은 부분은 확장성!!!!
담에 객체화 할 떄는 단일책임으로 분류 하는거에 확장상을 고려해봐서 하면 좋을 거 같다..
※ 오늘의 회고
일단 오늘 튜터님 오셨을 때.. 무사히 통과해서 다행이었다.. 사실 만들고 나니깐 너무 아쉬운 부분이 많아서 안타까웠다. .특히 스파게티 형식으로 다양하게 접근 할 수 있는 부분에 대해서 넘 아쉬웠다. 담에는 좀 더 구조화를 완성하고 구조화가 쉽게 되면 확장성에 대해서 생각해보고 싶다.
