GO SIWOO!

[객체지향의 사실과 오해] 4장 - 역할, 책임, 협력 [객체지향의 사실과 오해] 3장 - 타입과 추상화 [객체지향의 사실과 오해] 2장 - 이상한 나라의 객체 #0. 객체지향이란 현실 세계의 모방? 이 장에서는 '이상한 나라의 앨리스' 이야기를 통해 '객체 gosiwoo.tistory.com 0. 이 장에서는... 해당 책임과 메시지 장에서는 객체가 커뮤니케이션하는 방법인 메시지에 대해서 설명하고 있다 이전 장에서 메시지는 객체의 행동을 유발하는 것으로써 객체 간의 유일한 커뮤니케이션 하는 방법이라고 하였다. 거기에 더해 객체가 메시지를 받아 행동을 수행하는 것을 책임을 묶어 설명하고 있다. 객체에게 지워야 하는 책임의 수준과 자율성에 관해서 생각해 볼 수 있는 장이다. 1. 책임 책임이란 객체가 다른..

[객체지향의 사실과 오해] 3장 - 타입과 추상화 [객체지향의 사실과 오해] 2장 - 이상한 나라의 객체 #0. 객체지향이란 현실 세계의 모방? 이 장에서는 '이상한 나라의 앨리스' 이야기를 통해 '객체지향이란 현실 세계의 모방'이라는 객체지향의 gosiwoo.tistory.com 0. 이 장에서는... 개별 객체들 사이에 이루어지는 협력이 어떻게 이루어지고 있는지 설명하고 있다. 협력은 객체들이 각자의 역할 따른 책임을 충실히 이행하며 공동의 목표를 향해서 나아가는 과정에 대해서 설명하고 있다. 1. 협력 1장에서 쓰여있던 바리스타의 예와 같이 손님, 캐셔, 바리스타의 각자 맡은 역할을 요청과 응답으로 손님이 주문한 커피를 내오는 협력을 이뤄내고 있다. 이처럼 협력은 송신자의 요청과 수신자의 응답의 연..

[객체지향의 사실과 오해] 2장 - 이상한 나라의 객체 #0. 객체지향이란 현실 세계의 모방? 이 장에서는 '이상한 나라의 앨리스' 이야기를 통해 '객체지향이란 현실 세계의 모방'이라는 객체지향의 기본 개념의 오해에 대해서 설명한다. 객체는 현실 gosiwoo.tistory.com #0. 이 장에서는... 이전 장에서 현실 세계의 은유를 통해 객체를 설계하고 표현적 차이를 줄여 유지보수가 용이한 소프트웨어를 만들 수 있다고 하였다. 하지만 현실 세계는 복잡하다. 이 복잡한 것을 추상화하여 복잡성을 제거하고 객체지향 설계를 하는 것이 곧 객체지향 패러다임을 이용해 유용하고 아름다운 애플리케이션을 개발하기 위한 첫걸음이다. 추상화 과정은 뒤에 설명할 공통점을 취하고 세부적인 것을 제거하며 타입이라는 카테고리..

#0. 객체지향이란 현실 세계의 모방? 이 장에서는 '이상한 나라의 앨리스' 이야기를 통해 '객체지향이란 현실 세계의 모방'이라는 객체지향의 기본 개념의 오해에 대해서 설명한다. 객체는 현실세계의 모방이라고 배웠다. 그래서 우리는 사람과 휴대전화라는 객체가 있을 때 우리는 Person과 Cellphone이라는 이름의 객체의 설계도인 클래스를 만들 수 있다. 하지만 앞서 1장에서 한 말이 있다. 객체는 행동 통해 상태를 바꾸며 상태는 감추어진다. 객체는 메시지를 통해 협력을 하며 메시지에 대한 행동을 객체 스스로 선택할 수 있다고 했다. 위에서 만든 Person과 Cellphone 클래스로 만들어진 객체가 있을 때 Person 객체는 전화를 건다("010-1234-1234") 라는 메시지를 Cellphon..

'객체지향 프로그래밍'이라는 과목을 수강한 적이 있다. 해당 과목에서는 클래스, 캡슐화, 추상화, 상속, 다형성 등등에 대해 배웠고 객체라는 단어의 의미를 배웠다. 객체, 현실 세계에 존재하는 사물에 대한 추상화 객체는 현실 세계에 대한 투영이며 모방을 한다고 배웠다. 교수님 께서는 그에 대한 예로 자동차를 설명해 주셨던 기억이 있다. 실제 세계에서 차가 있고 이 차는 크게 보아 1개의 몸체, 4개의 휠, 타이어로 구성되어 있다. 이를 객체의 개념인 사물에 대한 추상화를 하면 Car라는 객체가 있고 이 Car에는 1개의 Body, 4개의 Wheel, Tire 등으로 구성이 되어있다고 할 수 있다. 하지만 이 책에서는 해당 개념, 현실 세계의 모방을 철학적인 개념을 설명하는 데에 적합하지만 실용적인 관점에..

1. 작게 만들어라 함수를 만드는 2가지 규칙은 작게 와 더 작게 이다. 작으면 작을수록 좋다. 중첩 구조가 생길 만큼 함수가 커져서 느 안된다. 함수에서 들여 쓰기 수준은 1단이나 2단을 넘어서면 안 된다. 2. 한 가지만 해라 함수는 한 가지를 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다. 우리가 함수를 만드는 이유는 큰 개념을 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서이다. 쉽게 함수를 한 가지만 하는지 판단하기 위해서는 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다. 3. 함수 당 추상화 수준은 하나로 함수가 한가지 작업만 하려면 함수 내 모든 문장의 추상화 수준을 동일해야 한다. #1. 동일한 추상화 수준? 추상화는 구체..

1. 의도를 분명히 밝혀라 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 위의 변수가 무슨 의도를 지니는 변수인지 알 수 없다.(거리(distance), 시간(date)??) 위처럼 의도가 분명한 이름을 만들자 코드가 단순하다고만 해서 코드의 이해를 짐작하기 쉬운 건 아니다. 이름의 함축성, 맥락이 코드에 드러나야지 함수가 하는 일, 코드가 하는 일을 이해하기 쉬워진다. 2. 그릇된 정보를 피하라 1. 널리 쓰이고 있는 의미의 단어를 다른 의미로 사용하지 말자(hp, iso, aco) 2. List는 프로그래머에게 특별한 의미이므로 실제 List가 아니라면 List를 다른 곳에 사용하여 그릇된 정보를 피하자. 3. 유사한 이름을 사용하지 말자, 서로 다른 모듈에서 비..

📌 기존의 회원기능 기존 프로젝트의 회원 기능은 kakao API를 통해서 진행했다. 그러나, 하드코딩 된 API 호출을 보고 적용하지 않고 프론트 팀에서 전달받은 인증 코드를 바탕으로 회원 정보를 HashMap 형태로 (설정파일도 사용하지 않았다) 이를 Controller 단에서 Session으로 저장해 두는 방식을 사용하였는데... @Service public class KakaoAPI { public String getAccessToken(String authorize_code) { String access_Token = ""; String refresh_Token = ""; String reqURL = "https://kauth.kakao.com/oauth/token"; try { URL url ..

📌 에러 개요 리팩토링 중 MyWord 엔티티에서 쿼리를 작성하는데 복잡한 쿼리를 마주했다. 기존 프로젝트 mapper를 통해 사용하던 쿼리는 다음과 같다. select distinct(word), mean from vocabularynote order by rand() limit 40; 퀴즈 템플릿을 반환하기 위해 40개의 튜플을 my_word 테이블에서 겹치지 않게, 랜덤으로, 특정 필드만을 프로젝션 해서 가져오는 쿼리이다. MySQL에서 작동하는 쿼리이기에 rand() 함수와 distinct() 함수, limit를 사용했고 word와 mean 필드를 가져왔다. 리팩토링을 하며 name(단어), morpheme(품사), mean(의미)로 morpheme을 추가시켜 가져오고자 하였다. @Getter @..

📌 기존의 프로젝트는? 팀 프로젝트를 처음부터 뜯어고쳐 리팩토링을 진행하기 위해서는 기존의 프로젝트의 DB 스키마와 작성한 API 명세를 파악해야만 했다. 캡스톤 디자인 과목을 통해 진행했던 만큼 프로젝트 보고서가 있어 DB 스키마와 구현 기능들의 파악은 어렵지 않았지만 API의 명세는 없어 하나하나 코드를 볼 수밖에 없었다. 📌 DB 스키마와 Entity 아래는 기존 팀프로젝트의 DB 스키마이다, 빨간색은 PK, 파란색은 FK로 표현되어 있다. 아래의 DB 스키마의 표현법도 다소 이상하다... 1 : N의 관계를 올바르게 표시하지 못했고 user 테이블, openDic 테이블, vocabularyNote 테이블 3개의 연관관계를 지니는 1 : N : M의 복잡한 구조도 띄고 있다. (이는 리팩토링을 통..