OOP44 12장 다형성 - 상속으로 타입 계층 정의하기 12장 읽고 나눈 이야기 자주 사용하는 자바 문법이 왜 존재하는지 알 수 있어서 좋았음. 근데 넘 복잡하다.. 이렇게까지 알아야함?? 면접 때 말할 일이 있지 않을까요. 그러네요 그래도 이 장의 핵심은 빨리 나온 듯. 계층 타입을 만드는 것은 곧 메서드 탐색 경로를 정의한다는 말이고, 이를 통해 다형성을 살릴 수 있다. 그나저나 js 내용 어렵네요. js는 이벤트를 핸들링하기 위한 reactive 언어여서 원래는 함수 위주의 언어인데.. 다형성을 갖춘 계층을 구현하기 위해 prototype 키워드를 두고 self 참조를 공유 가능하게 만든 것 같아요. (이 이후로 js에 대한 깊은 대화를 했고 나는 정신을 잃었다) 결국 이 장이 말하고자 하는 핵심 상속은 타입 계층을 정의한다. 이는 곧 메서드 탐색 경로.. 2024. 1. 31. 11장 합성과 유연한 설계 11장 읽고 나눈 이야기 믹스인.. 굉장히 독특하다! 구체적인 코드 조각을 섞음. 컴파일에 어떤 조각에 섞을지 결정하는데, 그 호출 시점은 동적으로 결정된다는 점이 흥미로움. 근데 이거 과연 좋을까? 그냥 합성하는게 좋지 않을까? 합성보다 유지보수 측면에서 믹스인이 더 좋을 것 같다는 생각. 명시적인 의존성이 클래스 이름에 드러나니까 컴파일 시점에 알 수 있을 듯. 근데 클래스가 늘어나는거 보면 합성이 좀 더 유리할 수도?? 11p347 코드 재사용은 상속보다 합성이 낫다. 상속은 부모 코드 전체를 재사용하지만, 합성은 부모의 퍼블릭 인터페이스를 재사용한다. 합성을 사용하면 클래스의 정적 관계 대신 객체 사이의 동적 관계를 사용할 수 있다. 변경 내용이 합성된 클래스에만 전파되므로 안정적이고, 필요한 코.. 2024. 1. 30. 10장 상속과 코드 재사용 10장 읽으면서 이야기 나눈 내용 Phone을 개선하는 과정을 보면서 작가님의 사고 흐름을 따라갈 수 있었음. 멋지다. 근데 과연 내가 할 수 있을까..? → 돌아가는 코드를 짜고 시간을 내서 이렇게 리팩토링하면 좋을 것 같은데요. 근데 리팩토링을 하더라도 기존 코드가 덜 깨지게 깨끗한 구조를 미리 만들어두면 좋을 듯. 금요일에 부동산 프로젝트하면서 재사용코드가 너무 많아서 괴로웠음. 파싱해온 데이터 속성 값에 따라서 다 다른 파서를 만들어서 문자열만 다르고 나머지 코드 다 복붙함. 심지어 파싱해서 반환하는 클래스도 동일함. 어떻게 개선할 수 있을까요? → 달라지는 부분만 생성자로 받아서 하나의 클래스로 합치는건 어떨까요? 아님 동일한 메시지를 가진 인터페이스를 뽑아서 추상 클래스로 구현을 추가하고 하위.. 2024. 1. 29. 9장 의존성 관련 조언 유연한 설계는 유연성이 필요할 때만 옳다 설계의 미덕은 단순함과 명확함이다. 변경에 대한 막연한 불안감은 불필요하게 복잡한 설계를 유발한다. 유연함은 단순함과 명확함의 희생 위에서 자란다. 단순함과 명확함을 만드는 방법은 사람들 간의 커뮤니케이션 뿐이다. 복잡성이 필요한 이유와 합리적 근거 없이는 누구도 복잡한 설계를 만족스러운 해법으로 여기지 않을 것이다. 단순하고 명확한 해법이 그런대로 만족스럽다면 유연성은 제거하라. 유연성은 코드를 읽는 사람들의 복잡함을 수용할 수 있을 때만 가치가 있다. 하지만 복잡성에 대한 걱정보다 유연하고 재사용 가능한 설계의 필요성이 더 크다면 코드의 구조와 실행 구조를 다르게 만들어라. 의존성을 관리하는 것보다 더 중요한 것은 협력에 참여하는 객체가 다른 객체에게 어떤 메.. 2024. 1. 25. 8장 의존성 관리하기 8장 읽고 이야기 나눈 내용 new는 해롭다. 그럼 어디에 둬야해? 생성자로 넘겨도 new는 써야하는 것 아닌가? → 팩토리 메소드처럼 의도적으로 높은 결합도를 갖는 대신 명시적인 의존성을 가진 클래스를 두는 방법도 있다. 그냥 읽을 때는 왜 이렇게 하는지 이해하지 못했는데, 나중에 컨텍스트를 확장해서 다른 요구사항을 추가하더라도 클래스만 추가해서 기능을 바꾸는 것이 인상적이었다. 하지만 이러한 설계가 꼭 필요한가 싶기도 하다. 유연함이 필요하지 않다면 클래스가 너무 많아지고 흐름 파악이 어려워보인다. 그 말을 들으니 기술 커뮤니티에서 들어본 기술부채라는 용어가 떠오른다. 우선 기한 안에 필요한 요구사항을 모두 구현하고, 따로 시간을 들여 더러운 코드를 정리하거나 유연함이 필요한 부분의 설계를 개선한다고.. 2024. 1. 25. 7장 패러다임 역사 7장 읽고 이야기 나눈 내용 프로그래밍 패러다임의 역사가 곧 소프트웨어의 역사와 결을 함께 하는 것 같다. 사람들이 점점 소프트웨어로 더 많은 일을 하기를 기대하고 비즈니스 시장이 커지니까 소프트웨어가 요구사항의 변경을 빠르게 반영해야할 필요성이 생겼고, 패러다임의 변화는 여기에 적응하기 위함이었던 듯. 소프트웨어가 충분히 발전해서 변경도 척척 반영할 수 있게 되면, 그 다음엔 뭐가 있을까요? 결국 목표는 많은 일을 빠르게 하는 것이니까, 다시 성능에 초점을 두지 않을까. 요즘 하드웨어 엄청 발전하고 있는데, 병렬로 발전이 일어나고 있는 것 같음. 그래서 캡슐화가 중요한걸까 더 효율적인 방법을 찾게 되면 기존 컴퓨터의 이진 체계나 폰 노이만 구조가 사라질 수도 있을 것 같다. 농도 컴퓨터라던지..? (아.. 2024. 1. 19. 이전 1 2 3 4 ··· 8 다음