본문 바로가기

CS/CS Book

 (25)
[오브젝트] ch02 객체지향 프로그래밍 🖋️ 후기 객체지향적으로 코딩을 한다고 하면 우선 클래스를 생각하고 동작이 무엇이고 그에 필요한 데이터는 무엇인가부터 생각했었습니다. 객체지향은 객체를 지향하라는 것. 그렇기에 클래스보다 객체에 초점을 맞추어야 진정한 객체지향 패러다임으로의 전환을 얻을 수 있다는 것이 인상 깊습니다. 어떤 객체가 필요한지 고민, 어떤 객체들이 어떤 상태와 행동을 가지는지 먼저 결정한다. 객체는 기능을 구현하기 위해 협력하는 공동체의 일원 객체지향에서 캡슐화가 중요하며 재사용성이 중요합니다 상속을 통해 중복되는 부분은 부모클래스로 받아와서 재사용성을 높일 수 있습니다. 하지만 상속의 경우 자식 클래스에서 부모클래스에 접근할 수 있고 부모클래스가 변동될 때 자식클래스도 바뀌기 쉽다는 점과 부모, 자식 클래스의 관계를 컴파일..
[오브젝트] Intro + ch01 객체, 설계 기억하고 싶은 부분 저자가 말하는 객체지향으로 향하는 세 걸음 클래스가 아니라 객체를 바라보는 것에서부터 시작 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 존재로 바라보는 것 협력에 참여하는 객체들에게 얼마나 적절한 역할과 책임을 부여할 수 있느냐에 달려 있다. 책에서 제시하는 방법이 객체지향을 구현하기 위한 유일한 방법은 아니다. 프로그래밍 패러다임이 중요한 이유 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다. 실무 vs 이론 (로버트 L. 글래스 ) 실무 방식을 선호 이유는 초기 단계에서는 실무를 관찰한 결과를 바탕으로 이론을 정립하는 것이 최선 컴퓨터 공학 분야는 역사가 다른 분야에 비해 상대적으로 짧다..
[서평] 로버트 나이스트롬의 인터프리터 in Java, C 길벗 출판사로부터 책을 제공받고 진행되는 서평임을 밝혀둡니다 처음으로 서평을 써보게 되었습니다. 어떻게 남기는 것이 좋을까 고민하다 보는 사람입장에서는 결론이 빠르게 나오고 궁금하면 이후에 근거나 추가설명을 찾아볼 수 있는 글이면 좋을 거 같아 읽고 개인적으로 생각해 보는 책의 특징과 추천독자를 적기로 하였습니다. 결론 인터프리터, 컴파일러가 어떻게 일하나 문자열 파싱은 어떻게 진행되는지 궁금하였는데 소스코드와 설명을 통해 이해하기 좋은 책입니다. EA, Google 출신 엔지니어의 친절한 설명과 코드로 인터프리터와 컴파일러를 만들어 볼 수 있습니다. Java로 시작하여 C도 써볼 수 있고 뒤에는 가비지 컬렉팅에 대해서도 배울 수 있습니다. 각 챕터가 적정 길이로 구성되어 부담이 덜한 편이며 중간 중간 ..
[Clean Code | 10장 클래스 ] Day15,16 기억하고 싶은 부분 클래스는 적어야 한다 단일 책임 원칙 클래스나 모듈을 변경할 이유가 하나뿐이어야 한다 변경할 이유가 하나여야 한다 클래스는 인스턴스 변수 수가 작아야 한다 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 높다. 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다 소감 객체에 대해 이야기할때 응집도와 결합도에 대한 말이 나온다 응집도는 높아야 하고 결합도는 낮아야 한다고 하는데 둘이 비슷하게 느껴져서 둘의 차이점이 무엇인가 생각 들곤 했었다. 책에서 응집도에 대해서 메서드에서 인스턴스 변수를 쓸수록 응집도가 높다는 설명에서 좀 더 감을 잡을 수 있었다. 필요한 건 있어야 하니까 필요한 건 멤버변수라 보면 메서드 입장에서 변수를 파라미터나 전역변..
[Clean Code | 9장 단위 테스트 ] Day14 기억하고 싶은 부분 TDD 세 가지 법칙 실패하는 단위테스트 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기로 한다. 깨끗한 코드 유지하기 개념당 assert 문 수를 최소로 줄여라 테스트 함수 하나는 개념 하나만 테스트하라 소감 깨끗한 코드 유지하기 부분이 납득되었다. 빠른 테스트를 위해 알아보기 어려운 상태의 테스트 코드를 작성하는 것은 나중에 바뀔 실제코드에 맞게 테스트 코드도 변경되어야 하므로 테스트 코드 변경을 어렵게 만들기에 그렇다 도서관 프로젝트에서 배포 전에 만든 단위 테스트가 얼..
[Clean Code | 7장 오류처리 ] Day10~12 기억하고 싶은 부분 뭔가 잘못될 가능성은 늘 존재한다. 뭔가 잘못되면 바로 잡을 책임은 바로 우리 프로그래머에게 있다. 어떤 면에서 try 블록은 트랜잭션과 비슷하다. try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다. null을 반환하는 습관 흔히 저지르는 바람에 오류를 유발하는 행위를 설명하면서 첫 번째 예시로 들음 null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다. 누구하나라도 null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모른다. null 확인이 너무 많아 문제. 메서드에서 null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체를 반환한다. 특수 사례 패턴 (SPECIAL CASE P..
[Clean Code | 6장 객체와 자료구조] Day09 기억하고 싶은 부분 “변수를 비공개로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서다.” private처리하는 목적으로 가져다 쓰는 입장에서는 내부가 어떻게 되어있든 혹은 특정 값에는 접근하지 못하게 하고 싶어서라고만 생각했었다. 같은 것을 의미하는 것일수도 있지만 조금은 다른 관점에서 private를 바라보았다는 생각이 든다. “변수를 private으로 선언하더라도 각 값마다 get함수와 set함수를 제공한다면 구현을 외부로 노출하는 셈이다” “인터페이스와 get/set 함수만으로는 추상화가 이뤄지지 않는다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. 아무 생각 없이 get/set 함수를 추가하는 방법이 가장 나쁘다.” private로 선언한 ..
[Clean Code | 5장 형식 맞추기 ] Day08 기억하고 싶은 부분 코드가 어수선해 보인다면 독자들은 프로젝트의 다른 측면도 똑같이 무성의한 태도로 처리했으리라 생각할 것이다 신문 기사처럼 작성하라 개념은 빈 행으로 분리하라 서로 밀접한 개념은 세로로 가까이 둬야 한다 지역변수는 각 함수 맨 처음에 선언해야 한다 소감 형식이라 하면 고리 타분하다 생각들 수도 있는데 사례들을 보여주어서 확 와닿았다. 가끔 알고리즘 문제 다른 이의 풀이를 보면 줄 수를 줄이기 위한 컨셉이지만 재미로 한 줄에 다 적는 경우도 있다. 그렇게 되면 그 글은 대강 보다가 말게 되는데 그런 점에서 들여 쓰기 없이 한 예시가 책에서 나오고 들여쓰기 있을 때와 비교되어서 확실하게 와닿았다 한 줄을 80자로 억제하는 규칙의 이름을 알 수 있어 나름 나에게는 유익하였고 저자는 120자를..
[Clean Code] Day07 Practice mission1.js // BAD 더러운 코드 😣 // Hint❕ : 검색하기 쉬운 이름을 사용하세요. // blastOFF는 로켓 발사를 의미. 86400000은 하루의 밀리초 (milliseconds) 의미. // What the heck is 86400000 for? // setTimeout(blastOff, 86400000); // GOOD 😎 // 위 코드를 깨끗하게 다시 작성해 주세요. const dayTimeMilliseconds = 24 * 60 * 60 * 1000; milliseconds setTimeout(blastOff, dayTimeMilliseconds); // 어떻게 고쳤는지, 사례에서 무엇을 배워야 하는지 설명해주세요. /** * const dayTimeMilliseconds..
[Clean Code | 4장 주석] Day05, 06 기억에 남는 내용 코드는 결국 바뀐다. 하지만 주석은 코드가 바뀌는 속도만큼 변화를 빠르게 반영하지 못한다 그런점에서 주석을 가급적 안쓰는 것을 권장하는 모습이 인상 깊다 이전에 "프로그래머의 뇌" 스터디를 하며 다른 분과 주석에 관해 생각을 나누었을 때 그분도 주석을 가급적 안쓰는 것을 선호하셨었다 나의 경우 주석이 있는 편이 설명이 되어서 좋지 않나라는 생각과 주석이 없어도 될만큼의 깔끔한 코드를 모든 코드에서 만들어내기는 힘들었고 협업을 같이하게 될때 팀원이 그렇다고 한다면 그에 맞추기 위해 클린코드를 지향하느라 부담이 느껴지고 서비스보다 깔끔한 코드에만 신경쓰게 될거 같아서 당시에는 약간은 거부감이 들었었다. 이 파트를 읽고보니 주석을 지양하는 태도를 가지신 분들의 생각도 이해가 되었다

티스토리툴바