객체 지향 프로그래밍이 실제 세계를 실제로 모델링합니까? [닫은]

나는 객체 지향 프로그래밍이 실제 세계를 모델링하는 것을 기반으로 반복되는 것을 보았습니다.

비즈니스 계층 외부의 것은 사실이 아닌 것 같습니다. 내 GUI 클래스 / 데이터 액세스 클래스는 실제로는 아무 것도 모델링하지 않습니다. 비즈니스 계층에서도 실세계 대상이 아닌 관찰자, 관리자, 공장 등의 수업이 있습니다. 캡슐화와 같은 것들을 활용하기 위해 클래스를 디자인하려고하지만 실제 세계가 캡슐화되어 있습니까?

내가 만든 일부 개체가 실제 개체를 모델링하는 동안 사전 OOP 코드가 동일하지 않습니까? OO가 코드베이스에 Customer와 같은 개념을 포함시킨 최초의 사람들인지 의심합니다. 그러나 OO는 실제로 물건을 모델링하는 방법에 관한 것이며, 그 모델링 방법은 실제 세계에서 영감을 얻지 못했습니다.

그렇다면 객체 지향 프로그래밍은 실제로 실제 세계를 모델링합니까?

아뇨, 전혀 아닙니다.

그러나 데이터 구조에 작용하는 일부 메소드와 함께 복잡한 데이터 구조를 보유하는 멋진 추상화를 작성할 수있는 방법론입니다.

어떤 종류의 모델이든 실제 세계를 모델링하지는 않습니다.

그들은 선택한 응용 분야, 사용중인 응용 분야와 관련된 부분을 모델링 합니다.

당신이 말하고있는 것 (관찰자, 관리자, 공장 등)은 추상화를 얻는 데 도움이되고 지속성과 같은 필요한 기능을 지원하는 인프라입니다.

어쨌든 모델이란 무엇인가 :
모델은 실제 시스템 또는 이벤트의 작동을 설명하는 데 사용되는 단순화 된 표현입니다.

객체 지향 프로그래밍을 통해 실제 세계를 모델링 할 수 있습니까?

분명하게 예입니다

실제와 정확히 일치하도록 시스템을 모델링하는 것은 거의 불가능합니다.

항상 실제 상황 이후에 소프트웨어를 정확하게 모델링해야합니까?

아니

모든 것을 모델링 할 수 있다고해서 모든 것을 모델링 해야하는 것은 아닙니다 . 실제로 유용한 모델링의 본질은 단순화 된 표현을 제시하는 것입니다. 현재의 비즈니스 요구를 표현하기에 충분한 단순화와 생략해야 할 것은 기술을 성공적으로 사용하는 것과 기술을 잃어버린 것 또는 전혀 사용하지 않는 것 사이의 미세한 균형입니다.

물론 존재하지 않는 엔티티가 있지만 모델링을 통해서만 실제로 개념화 할 수 있습니다.

명사와 계급 사이에 관계가 있다고 가르치면 성가신 나쁜 습관이 생겨나 고 나중에 조급 한 건축 가나 수석 엔지니어가 짓밟 아야한다고 생각합니다.

가르쳐야 할 것은 두뇌와 마찬가지로 클래스가 추상적 객체를 모델링한다는 것입니다. 당신은 당신의 머리에 어떤 "물리적 차"에 대응하지 않는 추상적 인 "차"개념을 가지고 있습니다. 그것은 재사용 가능하고, 특정한 차의 구현은 차에서 물려받을 수 있습니다. 당신의 두뇌는 심지어 당신을위한 메타 모델 개념입니다. 당신은 생각이 무엇인지, 개념이 무엇인지에 대한 정신적 모델을 가지고 있습니다.

우리가 사람들에게 이미 머리에서 생성하고있는 모델을 식별하도록 가르쳤다면 실제 소프트웨어를 구축 할 준비가 훨씬 더 낫습니다.

... 세상은 객체 지향 구문으로 표현할 수있는 것보다 훨씬 풍부합니다.

사람들이 모든 시스템을 이해하고 설명하기 위해 보편적으로 사용하는 몇 가지 일반적인 개념, 즉 물체 틀에 맞지 않는 개념을 고려하십시오. '이전 / 이후'패러다임뿐만 아니라 '원인 / 효과'의 패러다임과 '시스템 상태'의 개념이 가장 생생한 예 중 하나입니다. 실제로, '커피 양조', '차량 조립'또는 '화성에 로버 착륙'과정은 단순한 대상으로 분해 될 수 없습니다. 그렇습니다, 그들은 OO 언어로 그렇게 취급되고 있습니다. 그러나 그것은 생각과 반 직관적입니다. OO는 시퀀싱, 상태 또는 원인에 대한 개념이 없기 때문에 루틴 자체의 순서 – 어떤 인과 관계에 기초하여 어떤 조건 하에서 어떤 것보다 먼저 오는 것-OO에서는 의미있는 표현 이 없습니다.

프로세스는 실제 환경과 프로그래밍에서 매우 일반적입니다. 트랜잭션, 워크 플로우, 오케스트레이션, 스레드, 프로토콜 및 기타 본질적으로 '절차'개념을 처리하기 위해 수년에 걸쳐 정교한 메커니즘이 고안되었습니다. 이러한 메커니즘은 OO 프로그래밍의 고유 한 시간 불변 결함을 보완하려고 시도하면서 복잡성을 낳습니다. 대신 '전 / 후', '원인 / 효과', '시스템 상태'와 같은 프로세스 별 구성을 언어의 핵심 부분으로 허용하여 문제를 근본으로 해결해야합니다.

인용 출처 : Victoria Livschitz, 프로그래밍의 다음 단계

예, OO는 종종 실세계 엔티티를 모델링하는 데 사용될 수 있습니다.

비즈니스 계층에서도 실세계 대상이 아닌 관찰자, 관리자, 공장 등의 수업이 있습니다.

객체 지향 개발을 디자인 패턴과 혼동하지 마십시오. OO 분석 및 디자인은 프로그래밍 가능한 유지 보수 코드에 접근하는 수단입니다. 프로그래머는 OO 언어와 결합하여 캡슐화, 다형성 및 상속과 같은 OO의 기둥을 통해 재사용 가능한 코드를 생성 할 수 있습니다.

엔터티를 캡슐화하기 위해 실제 엔터티 이후에 해당 엔터티를 모델링 할 수 있습니다. 예를 들어, 기타가있는 경우 기타 클래스는 실제 기타의 동작과 속성을 캡슐화합니다. 우리는 IInventoryItem다형성과 상속을 통해 코드 재사용 가능성을 활용하기 위해 기타를 더 추상화 할 수 있습니다 .

반면에, 우리는 기타 공장이 다른 유형의 기타를 유지하는 데 도움을 줄 수 있음을 알 수 있습니다. 이것은 OO 때문이 아닙니다. 오히려 팩토리는 그러한 목적을 위해 유지 보수 가능한 코드를 성공적으로 작성하는 입증 된 수단으로 시간의 시험을 견뎌낸 디자인 패턴입니다. 다시 말해, 프로그래머는 종종 비슷한 문제를 해결하고 있습니다. 그래서 우리는 그것들을 해결하기위한 일반적인 해결책을 생각해 냈습니다 (바퀴를 재발 명하지 마십시오).

OO가 실제 세계를 모델링해야하거나 항상 가장 최적의 솔루션이라는 의미는 아닙니다. 간단히 말해,“실제 세계를 모델링하는 OO”는 완벽한 의미를 갖습니다.

그것은 당신이 말하는 실제 세계에 달려 있습니다.

호르헤 루이스 보르헤스는 "Tlön, Uqbar, Orbis Tertius"라는 이야기를 썼습니다. 이곳에서 주민 중 한 명은 현실 세계를 다르게 인식하는 것 같습니다.

[...] 상상의 T (Tlön) [...] 사람들은 세계의 현실을 부정하는 극단 형태의 버클리 이상주의를 가지고 있습니다. 그들의 세계는 "공간에서 물체의 동시성으로가 아니라 이기종의 독립적 인 행위로 이해된다." Tlön의 상상 언어 중 하나에는 명사가 없습니다. 중앙 단위는 "부 사력을 가진 단음절 접미사 또는 접두사로 인증 된 비 인용 동사"입니다. Borges는 "달 위에 물이 솟아 올랐다"라는 텔로 닉 (Tlönic)의 목록을 제시한다. [...] 텔론의 다른 언어에서, "기본 단위는 동사가 아니지만, 둘 이상의 조합으로 명사를 형성하는 단음절 형용사": "달"은 "풍선 발광" 어두운 "또는"

( 도서에 대한 위키 백과의 artice 에서 복사 )

나에게 요점은 세계가 우리와 다르게 인식 될 수있는 것이 아니라 일종의 진부한 것이지만 현실의 구조 자체에 대한 인식은 우리가 말하는 언어, 자연 또는 프로그래밍 언어에 달려 있습니다. Tlönese는 Lisp에 매우 만족할 것이며 Java (Aka The Kingdom Of Nouns )는 매우 부자연 스럽지만 대부분의 테란 프로그래머는 기능적 언어보다 객체 지향을 선호하는 경향이 있습니다. 나는 주로 두 가지 스타일을 좋아한다. 왜냐하면 그것이 주로 관점의 문제라고 생각하기 때문이다. 일부 문제는 기능적 측면에서 가장 공격적이며, 일부 문제는 객체 지향 프로그래밍 기술과 관련이 있습니다. 좋은 프로그래머는 솔루션을 시도하기 전에 항상 다른 각도에서 어려운 문제를 봅니다. Alan Kay가 말했듯이 : 관점은 80 IQ 포인트의 가치가 있습니다.

그래서, 당신의 질문에 대한 나의 대답은 : 당신은 어떤 실제 세계에 대해 이야기하고 있습니까? 그리고 어떻게?

내가 만든 일부 객체가 실제 객체를 모델링하는 동안 OOO 사전 코드가 동일하지 않습니까?

나는 말하지 않을 것입니다. OOP는 사물 (속성 / 오브젝트)과 그것들이 수행 할 수있는 / 할 수있는 것 / 방법 (방법) 사이의 관계를 묶는 반면, 절차 적 프로그래밍은이를 수행하지 않습니다 (엄격한 타이핑을 사용하는 경우는 제외). 모델은 개별 부품과 프로세스를 정의하는 것뿐만 아니라 서로 맞는 방식을 정의하는 것에 관한 것이기도하며 OOP가 특히 유용합니다.

객체 지향 프로그래밍이 실제 세계 모델링을 기반으로한다는 것이 일반적으로 반복되는 것을 보았습니다.

예. 여기에서의 강조는을 기반으로 합니다. OOP는 현실 세계를 모델링하지 않으며 (그렇다면 우연히) 의도하지 않습니다. OOP가하는 일은 실제 세계를 모델링하는 방식으로 프로그래밍 문제를 모델링 할 수있게하는 것입니다. 행동의 추상화를 통해 정의 된 엔터티 시스템입니다.

OO 코드는 일반적으로 실제 세계를 모델링하지 않습니다. 최소한 목표는 아닙니다. 실제 세계의 사물에 대해 생각하는 방식과 같이보다 자연스럽게 코드를 생각할 수 있습니다. 이것은 인용문이 말하려는 것입니다.

그것은 우리 세계를 모델화하지 않지만, 우리 세계의 인간 해석을 모델화합니다. 인간은 자연스럽게 사물을 사물로 분리합니다. OO는 인간이 생각하는 방식을 프로그래밍 할 수 있기 때문에 효과적입니다.

OOP는 실제 세계와 그 안에 포함 된 개체의 완벽한 모델이 아닐 수도 있지만 실제 소프트웨어의 복잡성이 증가하는 문제를 해결하는 데 도움이되는 방법입니다. 또한 논리적으로 관련된 청크로 분류하여 코드를 더 잘 작성하는 데 도움이됩니다.

오래된 절차 지향 방법으로도 결과를 얻을 수 있지만 OOP를 사용하면 크고 복잡한 프로젝트를 처리 할 때도 비교적 빠르고 쉽게 얻을 수 있습니다.

추상화 및 캡슐화는 실제로 문제가 발생하는 모든 배관을 숨기면서 문제의 핵심에 집중하는 데 도움이됩니다. 상속을 통해 코드의 다양한 측면간에 의미 있고 논리적 인 관계를 설정할 수 있습니다. 다형성은 코드 재사용을 촉진하고 변형을 쉽게 처리하고 ( " 기존 객체 와 거의 동일한 동작"문제가 자주 발생하는 문제 범주) 객체와 관련된 의미를 확장하여 코드를 확장합니다.

OOP는 실생활 시스템의 모든 복잡성을 효과적으로 처리 할 수 있는 입증 된 원조 라고 생각 합니다. 따라서 실제 세계에 대한 철저한 모델이 아닐 수는 있지만 충분히 가깝고 작업을 완료하는 데 도움이됩니다.

객체 지향 프로그래밍이 실제 세계 모델링을 기반으로한다는 것이 일반적으로 반복되는 것을 보았습니다.

비즈니스 계층 외부의 것은 사실이 아닌 것 같습니다.

아시다시피, OOP 언어로 "모델링 된"많은 것은 메시지 큐, 컨트롤러 및 스택과 같은 추상적 개념입니다.

비즈니스 계층에서도 여전히 "실제 세계"를 모델링하지 않습니다. 직원 클래스가 있다고 가정하십시오. 종업원은 또한 사람, 포유 동물, 동물 인, 또한 종업원입니다. (하품) 종업원은 좋아하는 색상을 가지고 있으며 특정 옷을 입고 특정 사물을 믿습니다. 요컨대, 현실 세계에는 대부분의 프로그램에서 캡처조차 시도하지 않는 엄청난 범위의 복잡성이 있습니다.

모델링에서 우리는 현재 작업에 의미가있는 모델의 측면에만 중점을 둡니다. 시간 입력 시스템을 디자인하는 경우 일종의 Employee 클래스가 필요하지만 해당 클래스에는 직원이 선호하는 색상을 표현하는 속성이 필요하지 않습니다.

따라서 모델은 "실제 세계"를 완전히 나타내려고 시도하거나 척해서는 안됩니다.

내가 만든 일부 객체가 실제 객체를 모델링하는 동안 OOO 사전 코드가 동일하지 않습니까? OO가 코드베이스에 Customer와 같은 개념을 포함시킨 최초의 사람들인지 의심합니다.

당신이 올바른지. OOP가 아닌 큰 프로그램을 보면 여전히 데이터 구조를 중심으로 구성됩니다. 데이터 구조와 조작하는 모든 기능은 명확성을 위해 서로 가까이 정의되어 있습니다. ( subversion 프로젝트 는 이에 대한 좋은 예입니다. 데이터 구조와 함수 앞에는 모듈 이름이 접두어로 사용되어 어떤 구조와 함수가 서로 사용되도록 의도되어 있는지 알 수 있습니다.)

나는 프로그래밍 언어의 역사에 대해 전문가가 아니지만 OOP는 코드가 이런 방식으로 구성되었을 때 코드가 더 명확하고 이해하기 쉽다는 평범한 관찰에서 생겨 났다고 생각하므로 언어 ​​디자이너는 해당 유형의 조직이있는 언어를 디자인하기 시작했습니다. 더 엄격하게 시행됩니다.

OOP와 비 OOP의 가장 큰 차이점은 OOP가 코드를 데이터에 바인딩한다는 것입니다. 따라서 다음과 같은 코드를 호출하는 대신

verb(noun);

우리는 대신 이것을한다 :

noun->verb();

이것은 문법상의 차이처럼 보일 수 있지만, 그 차이는 실제로 사고 방식에 있습니다. 우리는 물체에 무엇을해야하는지 알려주고, 일반적으로 물체의 내부 상태 나 작동이 무엇인지 상관하지 않습니다. 객체를 설명 할 때는 객체를 다루기 위해 공용 인터페이스 만 설명하면 됩니다.

객체 지향 프로그래밍이 실제 세계를 실제로 모델링합니까?

완전한 것은 아니고.

현실 세계에서 우리는 실제 문제에 직면합니다. 우리는 모델이 될 시스템을 복제하는 패러다임을 사용하여이 문제를 해결하고자합니다.

예를 들어, 장바구니 애플리케이션이 문제인 경우 다음과 같은 엔티티가 있습니다.

1. Book, Gadgets, Cars와 같이 여러 멤버를 가질 수있는 추상적 용어 인 제품 으로 다시 세분화 될 수 있습니다.

2. (판매 세)와 같은 세금 기준 은 정부 정책에 따라 소프트웨어가 변경 될 때 구현되는 위치에 따라 다릅니다.

3. 세금 은 제품이 세금 기준과 함께 수입되었는지 여부에 따라 고려됩니다.

4. 사용자 는 제품 목록이있는 장바구니 를 가질 수 있습니다 .

보시다시피 우리가 해결하려고하지만 실제 시스템에 최대한 근접하도록 OOP 패러다임으로 모듈화해야하는 실제 문제가 있습니다.

나는 당신이 매우 독창적이고 역사적이며 성명서가 될 내용을 너무 많이 읽고 있다고 생각합니다. OO 프로그래밍, 클래스, 다형성, 가상 함수 등의 많은 아이디어가 1960 년대에 Simula 언어로 소개되었습니다 (http://en.wikipedia.org/wiki/Simula). 이름에서 알 수 있듯이 Simula는 시뮬레이션 작성을위한 언어로 설계되었습니다. 따라서 역사적으로 OO 아이디어는 "실제 세계"를 모델링하기 위해 도입되었습니다. 그들이 다른 스타일보다 더 성공할지 여부는 논쟁의 여지가 있습니다.

내가 만든 일부 객체가 실제 객체를 모델링하는 동안 OOO 사전 코드가 동일하지 않습니까?

OOP와 pre-OOP 코드의 가장 큰 차이점은 전자가 상호 작용하는 서로 다른 개체 그룹으로서 실제 상황을 모델링한다는 것입니다. 각 개체는 수행 할 수있는 작업에 대해 제한된 "파워"를 가지고 있으며 자체 행동으로 외부 이벤트. 후자는 모든 것을 자체적으로 수행하지 않는 큰 데이터 덩어리로 모델링하는 반면, 계산은 "발생하는 것"을 나타내며 일부 또는 전부에 영향을 줄 수 있습니다.

현실 세계를 더 잘 모델링하든 없든, 그것은 실제로 모델링하려는 세계의 측면에 달려 있습니다. 예를 들어, 불이 켜진 물체에 불이 붙는 효과를 설명하려는 물리 시뮬레이션은 빛과 열이 모두 잘 통하기 때문에 "전통적인"접근 방식으로 더 잘 표현됩니다. 정의 된 프로세스는 다른 객체의 외부 및 내부 상태에 모두 영향을 미치며 각 특정 객체의 동작에 따라 다르지 않으며 해당 속성에만 영향을받습니다.

반면, 원하는 동작을 생성하기 위해 상호 작용하는 다른 구성 요소를 모델링하는 경우 수동적 인 작업 대신 에이전트로 처리하면 아무 것도 놓치지 않고 올바르게 수행 할 수 있습니다. TV를 켜려면 버튼을 누르기 만하면됩니다. 전원 코드가 뽑혀 있으면 TV.turnOn나를 확인합니다. 따라서, 코그 자체 (정확하게 프로그래밍 된 경우)가 1 차 코 그로 인한 2 차 인터랙션을 처리하므로 코 그를 돌리거나 코 그에 닿은 다른 것을 돌리는 것을 잊을 위험이 없습니다.

그러나 OO는 실제로 물건을 모델링하는 방법에 관한 것이며, 그 모델링 방법은 실제 세계에서 영감을 얻지 못했습니다.

세상이 실제로있는 것보다 세상 을 인식하는 방식과 더 관련이 있다고 생각합니다 . 우리는 모든 것이 단지 원자 (또는 에너지, 파동 등) 일 뿐이라고 주장 할 수 있지만, 주변 환경을 이해하고 미래의 사건을 예측하면서 우리가 직면 한 문제를 다루는 작업을 처리하는 데 도움이되지는 않습니다 ( 또는 과거의 것을 설명). 따라서 우리는 세계의 "정신 모델"을 만들고 종종 이러한 정신 모델은 데이터 + 프로세스보다 OO와 더 잘 일치합니다. 실제 세계가 실제로 어떻게 작동하는지 "더 나은"것으로 모델링합니다.

또한 대부분의 사람들이 OOP를 분류 및 사물의 하위 집합을 생성하고 객체를 매우 구체적인 세트에 명확하게 넣는 "클래식 OOP"와 동의어로 생각합니다. 재사용 가능한 새 유형 을 만드는 데 매우 유용 하지만 모델링하는 엔터티가 거의 자체 포함되어 있고 다른 개체와의 상호 작용을 시작하는 동안에는 그다지 중요하지 않지만 상호 작용의 대상은 아닙니다. 또는 더 나쁜 것은, 그 전체의 인스턴스가 거의 없거나 (아마도 하나 일 수도 있음), 인스턴스의 구성, 동작 또는 둘 다가 크게 다른 경우입니다.

그러나 "프로토 타입 OOP"도 있습니다. 여기서 유사한 오브젝트를 선택하고 다른 점을 열거하여 오브젝트를 설명합니다. 나는 이 글 을 사고 과정에 대한 훌륭하고 기술적으로 설명하지 않기 위해이 에세이 를 제안 할 것이다 (Steve Yegge의 표준조차도 전체 게시물이 너무 큽니다. 따라서 관련 섹션을 가리키고 있습니다. 다시 말하지만, 이것은 알려진 인스턴스와 비교하여 알 수없는 인스턴스를 상상할 때 우리의 정신 모델과 잘 일치하지만 실제 세계가 어떻게 작동하는지 반드시 그렇지는 않습니다 ... 여러면에서 "같은"것으로)

"Does"가이 질문의 중요한 부분이라고 생각합니다. 확실히 객체 지향 프로그래밍은 실제 "객체"를 모델링 할 수 있다고 생각 하지만 이것이 프로그래밍 입니다. 없습니다 더 악용 될 수없는 방법은, 그래서 당신이 객체와 바보 같은 일을 할 수있다해서 "OOP는 현실 세계를 모델링하지 않습니다"라고 공평하다고 생각하지 않습니다. 포인터로 바보 같은 일을 할 수 있기 때문에 포인터가 안전하지 않다고 말하는 것보다 공정하지 않습니다.

이 문제에 관한 Wikipedia의 기사 는 다음과 같이 요약합니다.

실제 모델링 및 관계
OOP를 사용하여 실제 객체 및 프로세스를 디지털 대응 물과 연결할 수 있습니다. 그러나 모든 사람이 OOP가 직접적인 현실 세계지도를 가능하게하거나 (부정적 비판 섹션 참조) 현실 세계지도가 가치있는 목표라고 동의하는 것은 아니다. Bertrand Meyer는 객체 지향 소프트웨어 구성 [21]에서 프로그램은 세계의 모델이 아니라 세계의 일부 모델이라고 주장합니다. "현실은 사촌이 ​​두 번 제거되었습니다."

문제는 프로그램이 우주 시뮬레이션이 아니라면 현실 세계의 일부, 즉 "모델" 만 신경 쓰는 것입니다. 그것이 모델의 목적이며, 표시해야 할 구조와 기능을 제공합니다.

현실 세계에는 사물 (사물)이 있으며 사물 (방법)을 수행 할 수 있습니다. 사물 (속성)의 측면을 정량화 할 수 있습니다. OOP는 축소 방식으로 사용될 때 실제 사물을 모델링 할 수있는 모든 잠재력을 가지고 있습니다. 모든 복잡한 것들은 더 작거나 더 구체적인 서브 클래스를 가지고 있으며이 모든 것들은 메소드를 통해 자연스럽게 상호 작용합니다.

OOP는 추상화하는 방법이므로, 실제적인 것은 OOP 정말 여부 논리적으로 현실 세계에서 모델 객체는, 당신이 모델링하지 않는 것이 덜 중요 할 이제까지 수있는 모든 단일 가능한 일이 다 . 가능한 모든 단일 작업을 수행해야한다면 실제로 모델링 하는 것은 아닙니다 .

적절한 컨텍스트에서 객체 지향에 대해 생각하기 위해 한 단계의 추상화를 진행하고 일반적인 프로그래밍에 대해 이야기 해 봅시다.

OO를 사용하든 기능적으로 접근하든 관계없이 프로그램은 무언가 를 해야 합니까? 프로그램의 요점은 특정 자극 세트가 주어지면 특정 행동 을 나타내는 것 입니다. 따라서 프로그램이 존재하는 이유 는 무언가를 하기 때문 입니다. 여기서 핵심은 행동 입니다.

프로그램이 구현해야하는 동작을 고려하는 것 외에도 프로그램은 일반적으로 특정 특성을 보여야합니다. 예를 들어, 심장 모니터 프로그램에 필요한 동작을 수행하는 것만으로는 충분하지 않습니다. 일반적으로 거의 실시간으로 작동 할 수있을 정도로 빠르게 수행해야합니다. 프로그램이 보여줄 필요가있는 다른 "품질"은 보안, 유연성, 모듈성, 확장 성, 가독성 등입니다. 이를 아키텍처 품질 속성이라고 합니다. 따라서 프로그램이 특정 행동 (기능적) 목표를 충족해야하며 특정 특성 (비 기능)을 나타내야한다고 말할 수 있습니다.

지금까지 이것 중 어느 것도 OO에 대해 이야기하지 않았습니다. 지금 해보자.

엔지니어가 요구 사항 (행동, AQA, 제약 조건 등)을 이해하면 문제가 발생합니다. 유용한 프로그램이되기 위해 필요한 자질을 발휘하면서 필요한 모든 작업을 수행하도록 코드를 어떻게 구성해야합니까? 객체 지향 프로그래밍은 프로그램 기능을 협력 객체의 응집력있는 모듈로 구성하기위한 전략입니다. 함수형 프로그래밍은 프로그램의 기능을 구성하는 또 다른 전략 일 뿐이며 다른 방식으로 수행됩니다. 두 전략 모두 장단점이 있습니다.

우리는 기능적 개념의 최근 부활을 목격하고 있으며, 그 이유는 무엇보다도 방대한 분산 처리에 매우 강력한 장점을 가지고 있기 때문입니다.

그러나 OO로 돌아 가면 "실제 세계"를 모델링 할 필요는 없습니다. 그것이하는 일은 프로그램이 여러 비즈니스 목표를 충족시키는 데 필요한 자질을 보일 수 있도록 프로그램의 동작을 구성하는 것입니다. TDD, DDD 및 BDD와 같은 기술은 객체를 가장 잘 구성하는 방법을 찾는 방법입니다. 원리, 패턴 및 실습 , 테스트 에 의해 유도되는 객체 지향 소프트웨어 성장 , 예제 별 사양 및 도메인 기반 설계 와 같은 책 은 행동 중심 설계에 중점을 둔 객체 지향 이론과 실습을 제시합니다.

"관찰자, 관리자, 공장 등"에 대해 읽을 때 프로그램이 유용 할 수있는 특정 특성을 나타내는 데 도움이되는 OO 패턴을 적용하고 있습니다. 요구 사항이 패턴이 해결하는 문제와 일치 할 경우 "작동하는 경향이있는"입증 된 레시피입니다.

OO와 기능적 패러다임간에 너무 편향되지 않고 OO가 무엇인지 이해하는 데 도움이되기를 바랍니다.

OOP는 프로그래밍 관점에서 멋진 모델을 만들지 만 실제 세계를 반영하지는 않습니다.

그러나 DSL (Domain Specific Language)이라는 용어로 알려진 실제 세계에는 훨씬 더 나은 근사가 있습니다 . 예를 들어 Boo 는 사람이 읽을 수있는 코드를 거의 평범한 영어로 작성하는 기능을 제공합니다 ( 기사의 샘플 ).

apply_discount_of 5.percent:
         when order.Total > 1000 and customer.IsPreferred
         when order.Total > 10000

suggest_registered_to_preferred:
         when order.Total  > 100 and not customer.IsPreferred

또 다른 예로는 Gherkin 언어를 기반으로 한 자동화 된 사용자 승인 테스트 프레임 워크가 있습니다.

Feature: Some terse yet descriptive text of what is desired
    In order to realize a named business value
    As an explicit system actor
    I want to gain some beneficial outcome which furthers the goal

Scenario: Some determinable business situation
    Given some precondition
        And some other precondition
    When some action by the actor
        And some other action
        And yet another action
    Then some testable outcome is achieved
        And something else we can check happens too

마지막으로 당신에게 달려 있습니다. 그러나 OOP는 Structured 또는 Procedure-oriented 프로그래밍과 같은 다른 방법론보다 정확한 방법입니다. 절차 적 전술은 문제를 해결할 수 있지만 OOP를 따르면 인생을 더 쉽게 만들 수 있습니다.