![]()
와, 블로그에 정말 오랜만에 들어왔다. 글을 쓰는것도 정말 오랜만이다. 사실 그 동안 매우 바빴다.우테코 합격을 준비하던 스터디는 21인의 개발자 스터디로 성장했고, 팀 프로젝트를 진행하고 있으며, 최근에는 참 감사하게도 구름톤 10기에 선발되어 해커톤에 필요할 만한 것들을 공부하는 중이다. 아무튼 근황을 하나씩 소개해보려 한다.몰입하는 개발자 스터디, 'CHZZK' 취지직취지직 - 개발자 취준 스터디. 취지직 has 11 repositories available. Follow their code on GitHub.github.com CHZZK (취지직) 스터디는 우테코 프리코스 합격 과제를 대비하던 '타임어택 스터디' 가 많은 최종 탈락자들과 함께(...) 개발자 스터디로 전환된 케이스다. 초기에 ..
![]()
다형성의 기본 개념정의다형성이란 '많은 형태를 가질 수 있는 능력'을 의미한다. Java에서 다형성은 한 객체가 여러 타입의 인스턴스로 행동할 수 있게 하는 특성을 말한다. 이는 주로 상속과 인터페이스를 통해 구현된다. (+현업에서는 상속보다는 인터페이스를 통해서 다형성을 구현하는 경우가 더 많다.)타입의 호환성Java에서 하위 클래스의 객체는 상위 클래스 타입으로 선언될 수 있다. 이는 상위 클래스 타입의 참조 변수가 하위 클래스의 인스턴스를 참조할 수 있음을 의미한다. 다형성의 장점코드의 유연성같은 코드 라인이 여러 타입의 객체에 대해 다른 동작을 수행할 수 있으므로, 객체를 다양한 상황에서 더 유연하게 사용할 수 있다. (제네릭, 형변환도 다형성이 확장된 개념이다.)다형성의 구현 다형성을 구현하기 ..
A is B.상속의 기본 개념정의 상속은 한 클래스(부모 클래스 또는 슈퍼클래스)의 속성과 메서드를 다른 클래스(자식 클래스 또는 서브클래스)가 이어받는 것을 말한다. 이를 통해 자식 클래스는 부모 클래스의 모든 기능을 사용할 수 있으며, 필요에 따라 추가적인 기능을 구현하거나 기존 기능을 재정의(Override)할 수 있다재사용성 상속은 코드의 재사용성을 높인다. 공통적인 기능을 부모 클래스에 정의하고, 이를 여러 자식 클래스에서 확장하여 사용할 수 있다. 상속의 장점코드 재사용기존 클래스의 코드를 재사용하여 새로운 클래스를 생성할 수 있다. 이는 개발 시간을 단축시키고, 코드의 중복을 방지한다. 유지보수의 용이성공통된 기능이 부모 클래스에 중앙집중화되어 있기 때문에, 수정이 필요할 경우 한 곳에서만 ..
캡슐화의 기본 개념 정의캡슐화는 객체의 데이터(상태)와 그 데이터를 조작하는 메서드(행위)를 하나의 단위로 묶는 것을 의미한다. 이를 통해 데이터와 메서드가 서로 밀접하게 연관되며, 객체의 내부 구현은 외부로부터 숨겨진다.정보 은닉(information hiding)객체의 내부 상태는 외부에서 직접 접근할 수 없도록 숨겨지며, 오직 객체가 제공하는 메서드를 통해서만 조작될 수 있다.이로 인해 내부의 구현은 감추고 한 모듈 내에서의 응집도(얼마나 관련성이 높은 책임들이 할당되었는지)를 높여 외부로의 노출을 최소화한다. 이로 인해 코드의 유연성과 유지보수성을 높일 수 있다.(정보 은닉은 캡슐화로부터 파생된 보조 개념이다. 캡슐화 = 정보 은닉은 아니다.)캡슐화의 목적과 장점 유지보수성객체의 내부 구현이 외부..
절차적 프로그래밍객체 지향 프로그래밍(OOP)의 등장 이전의 프로그래밍 패러다임은 절차적 프로그래밍이었다.흔히들 OOP의 반대가 절차적 프로그래밍이라고 생각을 하는데, 이는 틀린 사실이다. 절차적 프로그래밍의 프로시저가 OOP의 메서드로 확장된 것에 가깝기에, 완전히 일치한다고 볼 수는 없어도 서로 공유하는 부분이 차이보다는 더 많다. 그럼에도 불구하고 왜 OOP가 등장하였냐 하면, 절차적 프로그래밍은 데이터를 구조화 하지 못하는 한계가 있었기 때문이다. 절차적 프로그래밍에서는 데이터가 종종 전역 변수로 선언되어 사용되었는데, 이는 다양한 함수들이 동일한 데이터에 접근하고 수정할 수 있음을 의미했다. OOP의 관점에서 보면, "메서드1" 에서 사용되는 전역 변수 "변수1" 이 아무 관련도 없는 생뚱맞은..
![]()
6기 프리코스가 끝난지 벌써 4주가 다 되어 간다. 프리코스 종료 이후 회고글을 제외하고 처음으로 쓰는 포스팅인데, 요즘 뭐 했는지 근황을 한번 얘기해보려 한다. 타임어택 스터디 운영 프리코스가 끝나자 마자 타임어택 스터디를 만들어서 최종 코딩 테스트를 대비하고 있다. 원래는 인원을 나 포함 4명까지만 받으려 했는데, 예상 보다 훨씬 많은 분들이 스터디 가입을 신청해주셔서 총 10명이서 시간대별로 두 팀으로 나눠 진행하게 됐다. 신청자 모두를 받아서 3팀으로 운영할까 고민도 했는데, 나에게도, 스터디원들에게도 부담이 될 것 같아서 죄송하게도 모두를 받진 못했다 🥲 매주 월요일, 수요일의 정해진 시간에 게더타운에 모여 스터디를 진행했고, 아래와 같은 순서로 진행했다. 시작 시간이 되면 스터디 과제(이전 프..
![]()
프리코스 종료 4주간의 프리코스가 11월 15일자로 종료됐다. 내게는 정말 짧은 프리코스였다. 시간이 정말 빠르게 흘러갔고, 당장 지금도 새로운 과제를 받아 해야할 것 같은 기분이 든다. 프리코스가 끝나고 6일 뒤인 오늘 이 회고글을 쓰는데, 마음이 좀 허전하다. 열심히 어떤 것에 몰두하다가 그것이 끝을 맺었을 때의 허탈감, 원래라면 과제를 해야 하는데, 하지 않고 있다는 약간의 불안감. 이런 감정들이 조금 있어서 마음이 허전하다. 프리코스 중독인가...? 프리코스가 끝나고 뭘 했나? 일단은 개인적인 일정들을 처리했다. 교회에서의 업무도 있고 해서 프리코스가 끝난 주는 잘 쉬지는 못했다. 그리고 밀린 잠을 많이 잤다. 매일 평균 4-5시간 밖에 못 자서. 프리코스 당시에는 저것만 자도 괜찮았는데, 이제 ..
![]()
4주차 과제를 돌아보며 | 크리스마스 프로모션 레포 시간 과제 소요 시간 : 목~수 7일간 약 60시간 + 회고글 n시간 wakatime 으로 봤을 때, 7일간 IDE에 커서가 머무른 시간이 약 38시간이다. 설계에 한 3시간 쓴 것 같고, 나머지 시간은 학습에 사용했다. 주로 도메인 객체의 역할과 범위, SRP 원칙과의 충돌, 상태 관리의 주체, 제네릭의 조건 설정 등에 대해서 학습을 진행했다. 구현 정도 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항 전부를 만족했고, 테스트를 통과했다. 클래스 다이어그램 내가 작성한 전체 코드의 클래스 다이어그램이다. 특이한 점은 전략 패턴을 2군데(입력값의 메뉴 자동 분류, 할인 적용)에 사용했고, 평균적으로 하나의 도메인 객체가 하나의 서비스 클래..
![]()
이어서... 이번에도 6, 7일차를 같이 포스팅한다. 그 이유는 6-7일차의 일들을 딱딱 잘라서 말하기가 참 힘들기 때문이다. 6일차에 리팩토링한걸 7일차에 다시 리팩토링하고, 6일차에 완성되었다 생각했던 기능이 7일차에 버그가 발견되고... 이 이유 때문에 6, 7일차의 회고를 따로 작성할 수가 없었다. 커밋도 정말 기능 하나가 완성되었다 라는 판단을 하기 전에는 커밋 하기가 꺼려지는데, '어느 정도는' 완벽해지려는 내 성향이 영향을 미친 것 같다. 이번 회고록에도 모든 걸 담을 수 없으니, 고민하고 해결했던 대표적인 몇 가지만 적어보려고 한다. fix: 음료만 주문 시 금액 누적 버그 음료만 주문하여 에러 발생 시, 이후 주문에 에러가 난 음료 주문액이 누적되어 합산되는 버그가 발견됐다. 아래와 같이..
![]()
이어서... 오늘 4, 5일차를 한번에 쓰는 이유는, 계속된 고민과 고뇌와 수정으로 4일차에는 어떠한 한 기능을 완성했다- 고 말할 수 없었기 때문이다. 3주차 공통 피드백 중 객체를 객체스럽게 사용한다 라는 피드백에 정말 많은 찔림을 받았는데, 3주차 까지는 상태를 가지는 객체(Car, Lotto 등)가 스스로 일하기보다는 그저 값을 저장하는 저장소의 느낌이 강했다. 필드(인스턴스 변수)의 수를 줄이기 위해 노력한다 라는 피드백도 많이 찔렸는데, 도메인 객체가 하는 역할이 별로 없으니 컨트롤러와 서비스 클래스들이 많은 상태를 가지게 되었다. 그래서 객체가 객체스럽게 사용되기 위해 계속, 끊임없이 고민하고 수정을 거듭한 결과, 오늘 5일차에 한번에 기능들을 다 완성하게 되었다. 개선 vs 일단 돌아가게만..
이어서... OrderService 클래스 어제에 이어서, 주문에 필요한 모든 것들을 조립해 Order 클래스를 만드는 OrderService 클래스를 작성했다. import christmas.domain.order.Order; import christmas.domain.menu.strategy.AppetizerStrategy; import christmas.domain.menu.strategy.DessertStrategy; import christmas.domain.menu.strategy.DrinkStrategy; import christmas.domain.menu.strategy.MainDishStrategy; import christmas.domain.menu.strategy.MenuStrateg..
![]()
이어서... 오늘은 설계를 완료하고 조금의 코드를 작성했다. 양은 적지만 내 수준에서 추상화 퀄리티가 높은 코드를 작성한 것 같아 매우매우 뿌듯했다. 그리고 시간의 부담이 적으니 포스팅을 좀 더 정성들여 쓸 수 있게 됐다. 여전히 예쁘게 꾸미는 능력은 없지만, 내가 어떤 의문을 가졌고, 이를 해결하기 위해 어떤 고민을 했으며, 새로운 것을 학습했고 그 결과 이런 코드를 작성했다! 를 잘 보여주는 포스팅을 쓰려고 노력했다. 이게 매일매일의 내 성장 스토리니까. 설계 구현할 기능 목록 일단은 요구사항에 따라 구현할 기능 목록을 정리해 보았다. ## 구현할 기능 목록 * 입출력 * [사용자에게서 입력 받기] (서비스 로직) * [에러 메시지 출력] (서비스 로직) * [혜택 결과 출력] (서비스 로직) * 증..
