7장 패러다임 역사

 

7장 읽고 이야기 나눈 내용

• 프로그래밍 패러다임의 역사가 곧 소프트웨어의 역사와 결을 함께 하는 것 같다. 사람들이 점점 소프트웨어로 더 많은 일을 하기를 기대하고 비즈니스 시장이 커지니까 소프트웨어가 요구사항의 변경을 빠르게 반영해야할 필요성이 생겼고, 패러다임의 변화는 여기에 적응하기 위함이었던 듯.
• 소프트웨어가 충분히 발전해서 변경도 척척 반영할 수 있게 되면, 그 다음엔 뭐가 있을까요? 결국 목표는 많은 일을 빠르게 하는 것이니까, 다시 성능에 초점을 두지 않을까. 요즘 하드웨어 엄청 발전하고 있는데, 병렬로 발전이 일어나고 있는 것 같음. 그래서 캡슐화가 중요한걸까
• 더 효율적인 방법을 찾게 되면 기존 컴퓨터의 이진 체계나 폰 노이만 구조가 사라질 수도 있을 것 같다. 농도 컴퓨터라던지..? (아직은 공상과학 얘기임) 6G로 위성 통신을 지연 줄여서 한다던지? (낭만이 없네요)
• 다시 개발로 돌아와서, 시작은 추상 데이터 타입으로 하고 타입이 많이 추가되면 객체 추상화를 도입하는 게 합리적이지 않나. 근데 자바 인터페이스에 구현 추가할 수 있어요 default 필드로 추가 가능함. 그럼 추상 클래스랑 뭐가 달라요?? 그러게요..
• 기능 분해 방식이 알고리즘 풀이 접근법과 매우 유사하다고 느낌. 그래서 코테 문제 풀다가 개발 하면 코드가 금방 더러워지는 것 같다.

 

7장에서 살펴본 패러다임

• 기능 분해
• 모듈
• 추상 데이터 타입
• 객체

 

기능 분해

• 하향식 접근 : 최상위 추상 기능 → 구체적인 세부 기능
• 요구사항을 추가로 구현하게 되면 시스템 전체가 망가질 정도로 매우 취약함. 데이터의 결합도가 높기 때문
• 단점1 : 기능마다 main 메소드를 둘 수 없다.
• 단점2 : 실행 순서에 시간 제약이 발생. 데이터의 파급 범위를 예측할 수 없다.
• 이미 안정화된 솔루션에는 유용하다.

 

모듈

• 기능이 아닌 변경 정도에 따라 분해
• 모듈은 복잡성과 변경 가능한 설계를 감춤
• 변경범위가 모듈로만 한정되며, 관심사를 분리할 수 있음
• 인스턴스 개념이 없어 독립적인 단위를 다룰 수 없음

 

추상 데이터 타입

• 개별 인스턴스를 위한 타입
• 데이터와 기능을 분리하므로 로직에 데이터가 드러난다.
• 예를 들어 타입 필드를 포함하고 메소드에 조건문 사용

 

객체

• 개별 인스턴스에 상속과 다형성을 제공
• 데이터를 로직 안에 완전히 숨길 수 있음
• 타입 추가하더라도 기존 코드에 영향 없음. OCP

 

추상 데이터 vs 객체

• 프로시저 추가가 잦음 : 추상 데이터 타입이 유리
• 타입 추가가 잦음 : 객체가 유리