GYUD-TECH

프로젝트를 진행할 때, AWS EC2 서비스를 사용하면서 주로 리눅스 서버를 선택하여 사용하였다. 왜 리눅스 서버를 사용하는지, 리눅스 서버가 어떤 기능을 제공하고 어떻게 동작하는지는 모른 채 단순히 서버는 보통 리눅스를 사용한다는 이유로 서버를 선택했었다. 요즘에 클라우드와 도커와 관련된 개념을 공부하면서, 내가 한 선택에 왜 라는 질문을 달아보니 근거가 없이 대부분 사람들이 하는 방식을 따라했던게 많았던 것 같다. 서비스 마다 요구사항과 환경이 다르기 때문에 서비스에 맞는 선택을 해야한다는 것을 요즘 느끼고 있는데, 운영체제에 관한 지식이 이러한 선택을 하는데 도움을 준다고 생각하여 OS 면접 스터디에 참여하여 운영체제를 다시 복습하는 중이다. 이화여대 반효경 교수님의 "운영체제와 정보기술의 원리"를..

앞선 장의 마지막에 상속보다는 합성을 사용하자고 강조했다. 이번 장에서는 상속과 합성의 차이를 비교하고 왜 상속보다 합성을 사용해야 하는지에 초점을 맞추어서 공부하였다. 또한 중복 코드를 제거하는 또다른 방법인 믹스인의 개념도 함께 살펴보았다. 이번 장에서는 상속과 관련된 내용은 깊이 다루지 않기 때문에 이전 글을 한번 읽고 이번 장을 읽으면 더 이해하기 쉬울 것 같다. https://gyuwon-tech.tistory.com/37 [스터디: 오브젝트] 상속과 코드 재사용 이번 장에서는 상속과 코드의 재사용에 대해 다룬다. 프로그래밍을 공부하면, 중복코드를 줄이라는 말을 쉽게 들을 수 있는데, 왜 중복코드를 줄여야 하는지에 대해서 깊게 생각하진 않았던 것 gyuwon-tech.tistory.com htt..

이번 장에서는 상속과 코드의 재사용에 대해 다룬다. 프로그래밍을 공부하면, 중복코드를 줄이라는 말을 쉽게 들을 수 있는데, 왜 중복코드를 줄여야 하는지에 대해서 깊게 생각하진 않았던 것 같다. 왜 중복코드를 줄여야할까? 중복 코드의 문제점 지금까지 객체지향을 공부하면서 모든 문제는 변경에서 시작되었다. 애플리케이션의 변경은 필수적이고, 이제까지 변경에 유연한 코드를 만들기 위해서 여러가지 설계 기법을 공부했다. 중복코드는 변경을 어렵게 한다. 만약 중복 코드를 작성한 로직에 변경이 일어난다면, 중복 부분을 모두 찾고 일일이 변경해줘야 한다. 이로 인해 시간도 많이 걸릴 뿐더러, 버그의 가능성도 높아진다. 따라서 중복된 코드를 최대한 없에야 하는데, 이를 Dry(Don't Repeat Yourself) 원..

앞선 챕터에서 유연한 설계를 위한 의존성 설계 방법을 공부했다. 이번 챕터에서는 앞선 챕터의 내용을 명시적인 원칙으로 소개하여 앞장의 내용을 정리해 주었다. 이번 챕터를 읽을 떄 앞 장을 복습하고 읽으니 더 이해가 잘 되었던 것 같아서 이를 참고하는 것을 추천한다. https://gyuwon-tech.tistory.com/35 [스터디: 오브젝트] 의존성 관리 이번 장에서는 의존성, 의존성 전이, 의존성 해결에 관해 이야기 한다. 객체간의 협력을 위해서는 의존은 필수적이다. 하지만 과도한 의존은 나쁜 설계를 만든다. 시스템의 특징과 트레이드오프 gyuwon-tech.tistory.com 추가적으로 자바의 모듈과 패키지에 대한 내용이 짧게 등장하여 관련 내용을 찾아보았다. 모듈의 개념과 도입 배경 및 간단..

이번 장에서는 의존성, 의존성 전이, 의존성 해결에 관해 이야기 한다. 객체간의 협력을 위해서는 의존은 필수적이다. 하지만 과도한 의존은 나쁜 설계를 만든다. 시스템의 특징과 트레이드오프 관계, 예상되는 변경사항을 고민하여 의존성을 관리함으로써 최적의 설계를 만들자. 설계를 잘하는 것 만큼, 설계를 활용하여 변경에 잘 대처하는 능력을 기르는 것도 중요하다. 의존성 A라는 객체가 B라는 객체를 알고 있을 때, 'A가 B를 의존한다' 라고 한다. PeriodCondition 클래스를 예로 들어보자. public class PeriodCondition implements DiscountCondition { private DayOfWeek dayOfWeek; private LocalTime startTime; ..

책의 매 장마다 강조하는 내용은 메시지를 통해 협력하는 책임 주도 설계이다. 메시지를 먼저 생각하고 협력하여 캡슐화를 수행하고, 높은 응집도와 강한 결합도를 만든다. 이번 장에서 전달하고자 하는 궁극적인 내용은 위와 동일하지만, 좋은 인터페이스 설계를 위해 활용할 수 있는 몇가지 원칙을 추가적으로 소계한다. 원칙을 이해하기 전에 먼저 오퍼레이션의 개념에 대해 배워보자. 오퍼레이션 객체가 전달하는 메시지는 오퍼레이션명과 인자로 구성되고, 메시지 전송시에는 수신자가 추가된다. condition.isSatisfiedBy(screening); 위와 같이 메시지를 전송할 때 순서대로 수신자.오퍼레이션명(인자) 의 형태를 띈다. 이렇게만 보면 메서드명과 오퍼레이션명이 같은 것으로 오해할 수 있다. 앞서 배웠던 역할..