#객체지향 #오브젝트
프로그래밍 패러다임
- 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다.
- 또한 프로그래밍 패러다임을 교육시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비시킬 수 있다.
- 두 패러다임은 존재할 수 없는 것도 아니다. 절차지향 패러다임에서 객체지향 패러다임으로 전환됐다고 해서 두 패러다임이 존재할 수 없는 것은 아니다.
- 오히려 서로 다른 패러다임이 하나의 언어 안에서 공존함으로써 서로의 장단점을 보완하는 경향이 있다.
- ex) 절차형 패러다임과 객체지향 패러다임을 접목시킨 C++ 와 함수형 패러다임과 객체지향 패러다임을 접목시킨 스칼라(Scala) 가 있다.
- 이처럼 하나 이상의 패러다임을 수용하는 언어를 다중패러다임 언어(Multiparadigm Language)라고 부른다.
객체지향 패러다임을 주로 사용한다고 하더라도 다른 패러다임을 배우는 것이 도움이 된다는 사실을 알아야 한다. 은총알은 없다.
소프트웨어 모듈
모듈이란 크기와 상관 없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소를 말한다.
소프트웨어 모듈이 가져야 하는 3가지 기능
- 첫 번째 목적은 실행 중에 제대로 동작하는 것이다.
- 이것은 모듈의 존재 이유 라고 할 수 있다.
- 두 번째 목적은 변경을 위해 존재하는 것이다.
- 대부분의 모듈은 생명주기 동안 변경되기 때문에 간단한 작업만으로도 변경이 가능해야 한다.
- 변경하기 어려운 모듈은 제대로 동작하더라도 개선해야 한다.
- 세 번째 목적은 코드를 읽는 사람과 의사소통하는 것이다.
- 모듈은 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 한다.읽는 사람과 의사소통할 수 없는 모듈은 개선해야 한다.
제대로 실행되어야 하며 변경이 용이해야 하며, 이해하기 쉬워야 한다.
예시
현실상황에 대입을 해서 예제를 살펴보면 연극이나 음악회를 공연할 수 있는 소극장을 경영하고 있다.
작은 이벤트를 기획하기로 했는데 추첨을 통해 선정된 관람객에게 공연을 무료로 관람할 수 있는 초대장을 발송하는 것이다.
이벤트가 무사히 마감되었고 드디어 기다리던 공연이 시작되는 날이다.
소극장은 손에 초대장을 쥐고 입장을 기다리는 이벤트 당첨자들과 표를 구매하려는 관람객으로 장사진을 이루고 있었다. 이제 관람객들을 맞이해야 한다.
한가지 염려해야 할점은 이벤트에 당첨된 관람객들과 그렇지 못한 관람객을 구분해야 한다.
이벤트에 당첨되지 않는 관람객은 티켓을 구매해야만 입장할 수 있다. 따라서 관람객을 입장시키기 전에 이벤트 당첨 여부를 확인해야 하고 이벤트 당첨자가 아닌 경우에는 판매 후에 입장시켜야 한다.
하나의 클래스나 메서드에서 너무 많은 세부사항을 다루게 되면 코드를 작성하는 사람 뿐만 아니라 코드를 읽고 이해해야 하는 사람 모두에게 큰 부담을 준다.
변경에 취약한 코드
- 객체 사이의 의존성(dependency)과 관련된 문제이다.
- 문제는 의존성이 변경과 관련되어 있다는 점이다. 의존성은 변경에 대한 영향을 암시한다.
- 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포되어 있다.
-> 그렇다고 해서 객체 사이의 의존성을 완전히 없애는 것이 정답은 아니다.
객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것이다.
따라서 우리의 목표는 애플리케이션의 기능을 구현하는데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것이다.
-> 최소한의 의존성이라는 모호한 기준은 본인이 정하게 되는데 그 기준점을 정확히 알고 넘어가자!!!
또한 객체 사이의 의존성이 과한 경우를 가리켜 결합도(coupling)가 높다고 말한다.
반대로 객체들이 합리적인 수준으로 의존할 경우에는 결합도 낮다고 말한다.
결합도는 의존성과 관련되어 있기 때문에 결합도 역시 변경과 관련이 있다.
두 객체 사이의 결합도가 높으면 높을수록 함께 변경될 확률도 높아지기 때문에 변경하기 여려워 진다.
따라서 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이어야 한다.
이 글은 옵시디언에서 작성되었습니다.
#객체지향 #오브젝트
프로그래밍 패러다임
- 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다.
- 또한 프로그래밍 패러다임을 교육시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비시킬 수 있다.
- 두 패러다임은 존재할 수 없는 것도 아니다. 절차지향 패러다임에서 객체지향 패러다임으로 전환됐다고 해서 두 패러다임이 존재할 수 없는 것은 아니다.
- 오히려 서로 다른 패러다임이 하나의 언어 안에서 공존함으로써 서로의 장단점을 보완하는 경향이 있다.
- ex) 절차형 패러다임과 객체지향 패러다임을 접목시킨 C++ 와 함수형 패러다임과 객체지향 패러다임을 접목시킨 스칼라(Scala) 가 있다.
- 이처럼 하나 이상의 패러다임을 수용하는 언어를 다중패러다임 언어(Multiparadigm Language)라고 부른다.
객체지향 패러다임을 주로 사용한다고 하더라도 다른 패러다임을 배우는 것이 도움이 된다는 사실을 알아야 한다. 은총알은 없다.
소프트웨어 모듈
모듈이란 크기와 상관 없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소를 말한다.
소프트웨어 모듈이 가져야 하는 3가지 기능
- 첫 번째 목적은 실행 중에 제대로 동작하는 것이다.
- 이것은 모듈의 존재 이유 라고 할 수 있다.
- 두 번째 목적은 변경을 위해 존재하는 것이다.
- 대부분의 모듈은 생명주기 동안 변경되기 때문에 간단한 작업만으로도 변경이 가능해야 한다.
- 변경하기 어려운 모듈은 제대로 동작하더라도 개선해야 한다.
- 세 번째 목적은 코드를 읽는 사람과 의사소통하는 것이다.
- 모듈은 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 한다.읽는 사람과 의사소통할 수 없는 모듈은 개선해야 한다.
제대로 실행되어야 하며 변경이 용이해야 하며, 이해하기 쉬워야 한다.
예시
현실상황에 대입을 해서 예제를 살펴보면 연극이나 음악회를 공연할 수 있는 소극장을 경영하고 있다.
작은 이벤트를 기획하기로 했는데 추첨을 통해 선정된 관람객에게 공연을 무료로 관람할 수 있는 초대장을 발송하는 것이다.
이벤트가 무사히 마감되었고 드디어 기다리던 공연이 시작되는 날이다.
소극장은 손에 초대장을 쥐고 입장을 기다리는 이벤트 당첨자들과 표를 구매하려는 관람객으로 장사진을 이루고 있었다. 이제 관람객들을 맞이해야 한다.
한가지 염려해야 할점은 이벤트에 당첨된 관람객들과 그렇지 못한 관람객을 구분해야 한다.
이벤트에 당첨되지 않는 관람객은 티켓을 구매해야만 입장할 수 있다. 따라서 관람객을 입장시키기 전에 이벤트 당첨 여부를 확인해야 하고 이벤트 당첨자가 아닌 경우에는 판매 후에 입장시켜야 한다.
하나의 클래스나 메서드에서 너무 많은 세부사항을 다루게 되면 코드를 작성하는 사람 뿐만 아니라 코드를 읽고 이해해야 하는 사람 모두에게 큰 부담을 준다.
변경에 취약한 코드
- 객체 사이의 의존성(dependency)과 관련된 문제이다.
- 문제는 의존성이 변경과 관련되어 있다는 점이다. 의존성은 변경에 대한 영향을 암시한다.
- 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포되어 있다.
-> 그렇다고 해서 객체 사이의 의존성을 완전히 없애는 것이 정답은 아니다.
객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것이다.
따라서 우리의 목표는 애플리케이션의 기능을 구현하는데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것이다.
-> 최소한의 의존성이라는 모호한 기준은 본인이 정하게 되는데 그 기준점을 정확히 알고 넘어가자!!!
또한 객체 사이의 의존성이 과한 경우를 가리켜 결합도(coupling)가 높다고 말한다.
반대로 객체들이 합리적인 수준으로 의존할 경우에는 결합도 낮다고 말한다.
결합도는 의존성과 관련되어 있기 때문에 결합도 역시 변경과 관련이 있다.
두 객체 사이의 결합도가 높으면 높을수록 함께 변경될 확률도 높아지기 때문에 변경하기 여려워 진다.
따라서 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이어야 한다.
이 글은 옵시디언에서 작성되었습니다.
