lgvv98

오브젝트: 코드로 이해하는 객체지향 설계 11장을 읽으며 느낀점프로그래밍 언어의 발전과 구조에 대한 이론에 점점 더 흥미가 생기는 것 같음. 언어마다 다중 상속을 지원하지 않거나 mixin을 제공하는 방식을 보며 각 언어가 선택한 설계 철학과 구조의 차이를 이해하는 데 많은 인사이트를 얻음. 이러한 차이점은 단순히 문법적 요소에 국한되지 않고, 언어가 지향하는 객체지향의 특성과 설계 원칙에 깊이 뿌리를 두고 있다는 점이 체계적으로 언어를 잘 만든 것 같음. 합성과 유연한 설계상속이 부모 클래스를 자식 클래스를 연결해서 부모 클래스의 코드를 재사용하는 데 비해 합성은 전체를 표현하는 객체가 부분을 표현하는 객체를 포함해서 부분 객체의 코드를 재사용상속에서 부모와 자식 클래스 간의 관계는 컴파일 타임에 해결..

오브젝트: 코드로 이해하는 객체지향 설계 10장을 읽으며 느낀점상속은 경험에 의해서 기피하는 경향이 있는데, 문제에 대해서 다시보면서 인터페이스 상속이 아닌 구현 상속이 일반적으로 문제가 있구나를 알게 되었음. 상속과 코드 재사용객체지향 프로그래밍의 장점 중 하나는 코드를 재사용하기가 용이하다는 것.전통적인 패러다임에서 코드를 복사한 후 수정하는 것클래스를 재사용하기 위해 새로운 클래스를 추가하는 가장 대표적인 기법인 상속에 관해 살펴보기로 함.기존 클래스의 인스턴스를 포함시키는 방법으로 흔히 합성이라고 부름상속과 중복 코드중복 코드는 사람들의 마음속에 의심과 불신의 씨앗을 뿌림.눈 앞 코드가 어떤 코드와 비슷하다고 느끼는 순간 우리의 뇌는 혼란속으로 내던져 짐. DRY 원칙중복 코드는 변경을 방해함...

오브젝트: 코드로 이해하는 객체지향 설계 9장을 읽으며 느낀점개방 폐쇄 원칙 및 컴파일 타임 의존성, 런타임 의존성 보면서 기존 설계한 코드들을 다시 보게 되었음. 특히 Factory는 많이 사용하는데, 이거 어디에 위치시킬지 매번 고민했는데, 순수한 기술적 결정이므로 어디에 위치시킬지 명확한 근거를 알게 되었음. create, use를 분리하는거 경험적으로 행하고 있었는데, 문서로 보니까 더욱 좋았음! 유연할 설계이전 장에서는 재사용 가능한 설계를 만들기 위해 적용할 수 있는 다양한 의존성 관리 기번을 소개. 이번에는 원칙이라는 관점에서 정리개방 폐쇄 원칙은 확장과 수정이 키워드확장에 대해 열려 있다: 애플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 동작을 추가해서 애플리케이션의 기능을 확장..

오브젝트: 코드로 이해하는 객체지향 설계 8장을 읽으며 느낀점의존성에 대해서 더 잘 알게 되었음. 사내에서 이렇게 하면 더 좋겠다라고 생각해서 작성한 코드가 컨텍스트 확장과 조합 가능한 행동을 따른다는 데서 짜릿함을 느낌 의존성 관리하기잘 설계된 애플리케이션은 작고 응집도 높은 객체들로 구성협력은 필수적이지만 과도한 협력은 설계를 곤경에 빠뜨리기도 함.객체지향 설계란 의존성을 관리하는 것이고 객체가 변화를 받아들일 수 있게 의존성을 정리하는 기술변경과 의존성객체가 협력하기 위해 다른 객체를 필요로 할 때 의존성이 존재. 의존성은 실행 시점과 구현 시점에 서로 다른 의미를 가짐실행 시점: 의존하는 객체가 정상적으로 동작하기 위해서는 실행 시에 의존 대상 객체가 반드시 존재해야 함구현 시점: 이존 대상 객체..

오브젝트: 코드로 이해하는 객체지향 설계 7장을 읽으며 느낀점데이터 타입 추상화와 클래스의 차이를 더 명확하게 이해할 수 있었음. 객체 분해가 단순히 구조를 나누는 것이 아니라, 필요에 따라 정보의 복잡도를 관리하는 중요한 과정. 복잡한 시스템에서 모듈화를 통해 인지 과부하를 줄이고 코드의 가독성을 높이는 데 큰 도움이 된다는 부분 고민 프로그래밍 언어의 설계에 있어 왜(why)에 대해서 더 잘 알게 되었달까? 객체 분해개발자가 인지할 수 있는 용량을 초과하는 순간 인지과부하가 발생하여 문제 해결능력이 급격하게 떨어짐이를 위해 정보의 양을 조절하는 것불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 것을 추상화라고 함큰 문제를 작은 문제로 나누는 것을 분해(decomposition)이라..

오브젝트: 코드로 이해하는 객체지향 설계 6장을 읽으며 느낀점함수형 프로그래밍의 개념과 부수효과를 최소화하는 방법, 명령(Command)과 쿼리(Query)를 분리하는 설계 원칙에 대해 배운 것이 인상적이었음. 메시지를 통해 객체 간의 협력이 이루어질 때, 불필요한 부수효과를 피하는 것이 얼마나 중요한지 체감했고, 코드의 안정성과 일관성을 높이는 방법을 구체적으로 알게 되었음. 메시지와 인터페이스객체지향 프로그래밍에 대한 가장 흔한 오해는 애플리케이션이 클래스의 집합으로 구성된다고 생각하는 것. 클래스는 구현 도구일 뿐.가장 중요한 재료는 클래스가 아니라 객체들이 주고받는 메시지 클라이언트 - 서버 모델두 객체 사이의 협력 관계를 설명하기 위해 사용하는 전통적인 메타포는 클라이언트-서버 모델두 객체 사이..

오브젝트: 코드로 이해하는 객체지향 설계 5장을 읽으며 느낀점영화 설계를 바꾸는 모습을 보면서 어떻게 설계하는지에 대해서 생각을 많이 함. 재사용 되지 않는 메서드를 분리하면 시선이 분산되는 느낌이라 특정 메서드는 주석을 통해 전개하는데 몬스터 메서드라는 개념을 보면서 새로운 시각에 대해서 생각하게 됨. 책임 할당하기문맥을 벗어나 고립된 객체의 상태에 초점을 맞추기 때문에 캡슐화를 위반하기 쉽고 요소들 사이의 결합도가 높아짐. 다양한 객체 할당 방법이 존재하고 어떤 방법이 최선인지는 상황과 문맥에 따라 달라짐 데이터보다 행동을 먼저 결정하라객체에게 중요한 것은 데이터가 아니라 외부에 제공하는 행동. 객체지향 설계에서 가장 중요한 것은 적절한 객체에게 적절한 책임을 할당하는 능력 협력이라는 문맥 안에서 ..

오브젝트: 코드로 이해하는 객체지향 설계 4장을 읽으며 느낀점리플 이펙트와 강한 결합도의 문제를 다룬 코드 예제가 큰 인상으로 남음. 강한 결합도가 있을 때, 하나의 코드 변경이 시스템 전체에 걸쳐 어떤 파급 효과를 일으킬 수 있는지 직접 예제를 통해 보면서, 결합도를 낮추는 것에 대해서 고민하게 되었음. 코드의 유연성이 떨어지고, 작은 수정에도 많은 부분이 연쇄적으로 영향을 받는다는 점에서 코드의 유지보수성에 큰 장애물이 된다는 걸 체감. enum으로 값을 정의하는 코드들이 정의 케이스가 바뀌면서 외부에서 대응해주는 것들이 많았는데 이게 강한 결합도와 리플 이펙트 영역과 예시가 많이 닮아 있어서 좋은 인사이트가 되었다! 설계 품질과 트레이드오프객체지향 설계의 핵심은 역할, 책임, 협력임. 협력: 기능을..

오브젝트: 코드로 이해하는 객체지향 설계 3장을 읽으며 느낀점역할, 책임, 협력의 중요성에 대해 새롭게 이해하게 되었음. 특히 협력(collaboration)을 시작점으로, 이 협력 속에서 필요한 역할(role)을 정의하고, 적절한 객체(object)를 선택해 각 역할을 수행하게 하는 구조가 인상적이었음.객체는 구체적으로 클래스를 인스턴스화한 존재로서, 역할에 따라 협력 속에서 유기적으로 연결되고 책임을 다하도록 설계된다는 점. 역할, 책임, 협력객체지향 패러다임에서 핵심은 역할(role), 책임(responsibility), 협력(collaboration) 객체지향의 본질을 협력하는 개체들의 공동체를 창조하는 것.협력을 구성하기 위해 적절한 객체를 찾고 적절한 책임을 할당하는 과정에서 드러남역할, 책임..

오브젝트: 코드로 이해하는 객체지향 설계 2장을 읽으며 느낀점최근들어서 대규모 시스템 설계에서 합성의 중요성을 깊게 느끼고 있음. 경험에 의해서 상속은 부모 클래스가 비대해지고 확장성이 떨어지는 것 때문에 상속 자체를 꺼리고 있었는데, 객체 간 결합도를 높여 시스템 유지보수를 어렵게 만든다는 점을 이론적으로 이해할 수 있었음.합성을 통해 각 객체가 독립적으로 동작할 수 있도록 설계하는 것이 왜 중요한지, 그리고 이렇게 설계했을 때 시스템이 얼마나 유연하게 변화에 대응할 수 있는지를 다시 느낌. 설계에 근거를 점점 더 갖추게 되는 2장! 협력, 객체, 클래스객체지향은 객체를 지향하는 것이지, 클래스(class)를 결정한 후 어떤 어떤 속성과 메소드가 필요한 지 결정하느 는 것과는 거리가 멂.진정한 객체지..