클라이언트가 객체 지향 프로그래밍을 사용하지 않도록 요구 한 경우 어떻게 하시겠습니까?

그리드에서 개미 의 활동 을 시뮬레이션하는 프로그램을 작성 중입니다 (PDF). 개미는 움직일 수 있고 물건을 집어 들고 물건을 떨어 뜨릴 수 있습니다.

문제는 개미의 행동과 각 개미의 위치를 ​​클래스 속성으로 쉽게 추적 할 수 있고 (그리고 우리는 그러한 개미의 많은 인스턴스를 쉽게 만들 수 있음) 고객은 기능 프로그래밍에 대한 배경 지식이 있기 때문에 함수형 프로그래밍을 사용하여 시뮬레이션합니다.

분명히, 클라이언트의 원래 단어는 "클래스 없음"일 뿐이며 "기능적 프로그래밍"은 아닙니다. 그래서 나는 그가 함수형 프로그래밍을 의미하지 않는다고 가정하고 필연적으로 그것을 할 수 있습니다. 또한 함수형 프로그래밍에 대한 사전 경험이 없습니다.

그러나 나는 단순히 "필수적으로하는 것"보다는 기능적 프로그래밍 요구 사항에 대해이 질문에 초점을 두는 것이 유익하다고 생각합니다.

이 상황을 어떻게 처리 하시겠습니까? 객체 지향 프로그래밍을 사용하는 것이 훨씬 깨끗하다는 것을 고객에게 설득하고, 필요한 것을 따르고 품질이 낮은 코드를 제공하거나 다른 작업을 수행하려고합니까?

객체 지향 코드는 정의에 의한 것이 아니며 반대로 비 OO 코드는 정의에 의한 크 래피가 아닙니다. 이 특정 문제에 대한 객체 지향 매핑이 명백한 것처럼 보이지만 어쨌든 함수형 프로그래밍 접근법을 시도하는 것이 좋습니다. 최고의 기회를 제공하고, 최고의 기능적 프로그래밍 스타일로 문제를 해결하고, 예상치 못한 것을 배우십시오.

클라이언트가 기능적 언어로 프로그래밍하는 데 사용했음을 언급 할 수 있으며, 기능적 스타일로 코드를 작성해야하는 이유가있을 수 있습니다. 왜 그런지 물어봐야합니다 .

어쩌면 그는 코드를 유지하고 나중에 스스로 유지하려고 할 것입니다.

또한 두 가지 선택이 OO 스타일인지 또는 언급 한 것처럼 엉터리 코드를 작성하는 것 같지는 않습니다 . 이와 같은 예제에서 함수 코드를 작성하는 것이 더 어려울 수 있습니다. 특히 객체 지향 언어에 대한 경험이있는 경우 클라이언트가 함수 스타일에 익숙해지기를 조금 더 기꺼이 기다릴 경우 그에게 물어 보지 않았다.

나는 왜 그가 함수형 코드를 원 하느냐고 물을 것이고 시간이 그렇게 큰 문제가 아니라면 함수형 프로그래밍의 속도를 높이기 위해 며칠이 더 필요할 것입니다. (배우기 위해 돈을 버는 것에 대한 만세!)

다른 모든 방법이 실패하면 OO 스타일로 수행하는 데 훨씬 적은 시간이 걸릴 것이라고 설명하십시오.

함수형 프로그래밍은 "클래스없는 프로그래밍"을 의미하지 않는다는 것을 알고 있습니까?

전체 Schtick 에 대해서는 Wikipedia 기사를 참조하십시오 .

컴퓨터 과학에서 기능 프로그래밍은 계산을 수학 함수의 평가로 취급하고 상태 및 변경 가능한 데이터를 피하는 프로그래밍 패러다임입니다. 상태의 변화를 강조하는 명령형 프로그래밍 스타일과 달리 함수 적용을 강조합니다.

OO가 프로그래밍 패러다임 인 것처럼 함수형 프로그래밍은 프로그래밍 패러다임입니다.

당신의 배경이 OO에 있다면, 나는 당신이 모든 개미가 어떻게 객체가되고 싶어하는지 알 수 있습니다. 반면에 수백만 개의 개미가있는 개미 농장을 시뮬레이션하는 경우 OO 및 메시지 전달이 비효율적 일 수 있습니다.

운 좋게도 파이썬에는 함수형 프로그래밍을위한 훌륭한 도구가 있습니다 (가장 중요한 것은 함수가 일류 객체라는 것입니다).

파이썬 함수형 프로그래밍 하우투

고객에게 기능적 프로그래밍을 원한다면 전문적인 사람을 고용해야한다고 설명하십시오. 함수형 프로그래밍은 OOP와는 매우 다르므로 쉽게 선택할 수 있고 복잡한 고품질 솔루션을 제공 할 수 있다고 생각하면 실수 할 것입니다.

"OO"가 "기능"과 완전히 반대된다는 일반적인 오해가 있습니다. 이런 것들이 아주 잘 어울립니다. 귀하의 예에서, "Ant"는 클래스와 객체를 사용하여 직접 구현할 수있는 추상 데이터 유형으로 모델링 될 수 있습니다. "Ant 상태"사이의 전환은 함수를 사용하여 자연스럽게 모델링 할 수 있으며 "Ant"클래스가 변경 불가능한 유형 인 경우 기능적인 접근 방식으로 이어집니다.

그리고 객체는 가난한 사람의 클로저이고 가난한 사람의 객체는 ... ;-)이기 때문에 "객체"는 클로저의 기능적 개념에 의해 상호 교환 될 수 있습니다.

https://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean

https://stackoverflow.com/questions/501023/closures-and-objects

고객과 대화를 나눈 후에도 여전히 자신의 방식을 원한다면 전문적인 업무를 수행하거나 할 수없는 경우 계약을 체결하지 못하거나 다른 방법을 찾을 수 없습니다.

동의하지 않기 때문에 "크 래피 코드"를 생성하는 것은 매우 전문적이지 않습니다.

1. 클라이언트가 함수형 프로그래밍과 명령형 프로그래밍의 차이점을 알고 있다고 가정하는 이유는 무엇입니까? 많은 사람들이 비 OO 프로그래밍 패러다임의 이름이나 세부 사항을 알지 못하고 "절차 적", "제 국적"및 "기능적"과 같은 용어를 쉽게 바꿀 수 있습니다.

2. 그런 식으로 걸어야한다고 믿지 않는 한 다른 사람들이 걷도록 지시하지 마십시오. 따라서 함수형 프로그래밍이 적합하지 않다고 생각한다면 프로젝트를 반쯤 마비 시키거나 실패하도록 스스로를 설정하지 마십시오.

3. 클라이언트가 스펙을 작성하면 스펙을 구현하고, 그렇지 않으면 스펙을 작성하고 스펙을 구현 하십시오 .

4. 고객의 결정에 영향을 미치는 최선의 전략은 바람직하지 않은 옵션을 훨씬 더 비싸게 만드는 것입니다. 매번 작동합니다.

5. 당신이 전문가 인 경우 (고객과 관련하여) 설득 할 수 있어야합니다.

6. 클라이언트가 유효한 포인트를 가지고 있는지 실제로 알기 위해서는 함수형 프로그래밍에 대해 더 많은 경험을 쌓아야합니다. 그래야 자신감을 가지고 OO에 대한 편견이 귀하의 경험 부족으로 인한 것임을 알 수 있습니다.

7. 두 가지 방법을 모두 사용하여 클라이언트가 두 가지 구현을 모두보고 유지하기 쉬운 방법을 결정하도록하는 이유는 무엇입니까? 이 모든 것을 프로젝트 견적에 반영하면 비용을 지불하는 동안 학습 곡선을 즐길 수 있습니다.

더 이상 귀찮게하기 전에, 나는 당신이 똑같은 것에 대해 이야기하고 있는지 확인합니다. 소프트웨어가 언제 객체 지향적인지 물어볼 수 있습니다. 그는 자신의 주요 전문 지식이 아니라고 생각했다.

예를 들어 많은 사람들이

class C {
public:
  C();
  void f( int );
  void g();
};

고전적인 객체 지향 접근 방식이지만

struct C;
void construct( C ** );
void f( C *obj, int arg);
void g( C *obj );

(전통적인 "데이터와 함께 작동하는 기능과 함께 데이터"가 정의되는 한, 둘 다 똑같이 객체 지향적이지만).

객체 지향 프로그래밍을 사용하는 것이 훨씬 깨끗하다고 ​​클라이언트를 설득하려고하십니까?

프로그래밍 패러다임에 대해 더 많이 교육해야한다고 생각합니다. 객체 지향 프로그래밍 코드가 반드시 더 깨끗할 필요는 없으며, 실제로 적용 할 수있는 것은 아닙니다. 또한 좋은 객체 지향 코더는 절차 / 모듈 식을 사용하여 좋은 작업을 수행하는 방법을 알고 있습니다 (기능 및 선언적 패러다임을 사용하면 조금 어렵지만 읽기와 추론을 통해 좋은 프로그래머가 도착하기가 너무 어려워서는 안됩니다) -수용 가능한 FP / 선언 솔루션

절차 및 모듈 식 프로그래밍을 잘 이해하지 않고서도 객체 지향을 사용하는시기와 방법을 거의 이해할 수 없습니다. OO는 클래스와 상속 계층을 선언하는 것 이상의 의미가 있습니다.

아니면 그가 요구 한 것을 따르고 엉터리 코드를 주려고 하시겠습니까?

좋은 코드를 절차 적으로 작성할 수 없다면 객체 지향 방식으로 좋은 코드를 작성할 수 있을지 의심됩니다. 기간. 나는 여기서 판단하려고하지 않지만 이것은 주장되어야한다.

객체 지향은 절차 및 모듈 식 프로그래밍의 확장입니다. 객체 지향은 단순히 적절하게 사용될 때 캡슐화, 커플 링, 응집력 및 코드 재사용 / 확장 성 문제를 다루는 더 나은 메커니즘을 제공하는 도구를 제공합니다.

그러나 이러한 모든 문제는 OO 고유의 문제가 아닙니다. 그것들은 절차 적 / 모듈 식 코드 (그리고 그 문제에 대한 다른 패러다임)에 존재합니다. 이것은 본질적으로 패러다임에 무관 한 복잡성 문제의 유형입니다. OO 접착제없이 처리 할 수 ​​없으면 처리 할 수 ​​없을 것입니다.

=========

고객을 설득 할 것인지에 대한 원래의 질문으로 돌아갑니다. 따라 다릅니다. 포스터 Sean McMillan이 말했듯이, 고객이 단순히 일부 의제 (읽기, 사무실 정치)에 대한 개발 노력을 미세 관리하려고 시도하는 경우, 멀리 가십시오. 그러한 방해 행위를하는 사람들은 다른 사람을 비난하거나 특정 안건을 추진합니다. 당신은 그것에 참여하고 싶지 않습니다.

OTH에는 이러한 요구 사항에 대한 다른 이유가있을 수 있습니다. 많은 임베디드 상점은 옳고 그름에 관계없이 C ++로 수행 할 수있는 작업에 많은 제약을 두도록 선택합니다 (예 : 가상 방법, 예외 없음). 다른 경우에는 그렇게하는 데 유효한 기술적 이유가 있습니다.

따라서 클라이언트가 OO 코드를 피하려는 이유를 이해해야합니다. 그리고 정치적 의제가 없다고 생각할 수 있다면 (적색 플래그 없음), 전문적으로해야 할 일은 절차 상 / 모듈 식으로 코드를 작성하고 잘 수행하는 것입니다.

프로그래밍 패러다임과 무관하게 엉터리 코드를 전달할 이유는 없습니다. 하나의 패러다임으로 허용 가능한 코드를 생성 할 수없는 경우 일반적으로 허용 가능한 코드를 생성 할 수 없습니다.

데이터 구조와 객체 지향 프로그래밍을 혼합하고 있습니다 (이 OO에 감염된 세계에서 일반적인 혼란)

데이터 구조에서 "데이터 속성 추적"만하고 수정하면 70 년대 이후에 만들어진 거의 모든 언어가 OO를 지원할 수 있습니다.

OO에서 수행하기 쉬운 것은 대충

• 클래스 기반 상속 (오래된 것으로 가장하는 새 클래스를 쉽게 만들 수 있음)
• 클래스 기반 다형성 (나중에 시뮬레이션에 새로운 종류의 개미를 쉽게 추가 할 수 있음)

이 중 하나가 절실히 필요하지 않은 경우 기본적으로 프로그래밍 패러다임은 너무 많은 문제 없이이 문제를 해결해야합니다.

내 고객은 기능 프로그래밍에 대한 배경 지식이 있기 때문에 기능 프로그래밍을 사용하여 시뮬레이션을 만들고 싶다고 말했습니다.

(이것은 기술 / 디자인 문제로 잘못 알려진 사회적 문제의 또 다른 예입니다.)

여기에는 두 가지 가능성이 있습니다.

1. 고객은 작성한 코드를 작성하고 작성한 후에는 직접 코드를 적용하거나 유지할 수있을 것으로 기대합니다. 그렇다면 "하우스 스타일"에 대해 더 많이 알아야합니다. 기능적 대 OO는 빙산의 일각에 불과합니다. 고객이 이해하는 프로그래밍 스타일로 자신을 제한하거나 원하는 스타일로 고객을 교육해야합니다. (클라이언트가 변경을 원할 수 있기 때문에 템플릿 또는 라이브러리를 사용하지 않고 CGI로 웹 응용 프로그램을 작성하라는 요청을 받았습니다.)

2. 당신의 클라이언트는 어떤 의제 때문에 개발을 통제하려고합니다. 이것은 당신이 아무 것도 원하지 않는 미친 가득한 가방입니다. 실제로 "턴키"소프트웨어를 제공하는 경우, 클라이언트는 작업을 안정적으로 수행하는 한 바퀴에서 햄스터로 만들어 졌는지 신경 쓰지 않아야합니다. 이런 식으로 자신을 미세 관리하는 것은 단지 고통을 요구하는 것입니다.

당신이 어떤 상황에 있는지 결정하고 그에 따라 행동하는 것은 당신에게 달려 있습니다.

음 ... "이것은 분명히 테스트 작업 / 할당"이라고 생각하는 유일한 사람 입니까? .

첫째, 과제 자체는 본질적으로 일종의 "학술적"이다 (개미의 행동 양상을 시뮬레이션).

둘째-코드를 읽고 그러한 주장을 할 수있는 "클라이언트"의 매우 특정한 프로그래밍 패러다임 냄새를 사용 (또는 회피)하여 요구 사항을 구현하라는 요청.

이 경우 필요한 것을 더 잘 수행하십시오-오히려 좋은 학습 경험이 될 수 있으며 그렇게 할 수 있다면 그 과정에서 많은 것을 배울 것입니다 ...

그렇지 않은 경우에는 본인 및 / 또는 고객에게 할당에 대한 추론을 요청해야합니다. 추론이 확실하다면, 그렇게하십시오 – 배우고 경험에 대한 프로그래머로서 더 나을 것입니다. 누가 아는 사람-당신은 OO보다 기능적인 스타일을 좋아하는 법을 배울 수도 있습니다.

설명이 부족하면 모든 베팅이 해제됩니다. 어떻게해야하는지 추천 할 수 없습니다.

기능적 언어 / 스타일로 요구 사항을 구현하지 않고 시도하거나 비린내가 느껴지면 공손하게 제안을 거절 할 수 있습니다.

중요한 것은-요구 사항의 동기를 이해하면 적절한 행동 과정이 분명해진다는 것입니다.

편집 : 참조 된 PDF를 대각선으로 본 후에 거기에 설명 된 알고리즘은 OO가 아닌 기능적 스타일에 적합한 것으로 보입니다.

함수형 프로그래밍 사용 요청에는 몇 가지 좋은 측면이 있습니다.

1. 당신은 클라이언트가 있습니다, 그것은 항상 좋은 징조입니다
2. 고객은 귀하가하고있는 일에 능숙 할 것으로 기대합니다. 이것이 기능 프로그래밍을 요구하는 이유입니다. 따라서 영업 조직에서 일을 잘하고 있거나 서비스에 대해 높은 가격을 요구하고 있습니다.
3. 클라이언트 조직에는 함수형 프로그래밍이 좋은 일이며 미래에는 클 것 같은 사람들이 있습니다.

그러나 몇 가지 놀라운 징후가 있습니다.

1. 함수형 프로그래밍에서 구현할 준비가되어 있지 않은 것 같습니다. 기술이 약간 구식이며 변경 사항을 따라갈 수 없습니다.
2. 또는 고객이 실제보다 더 나은 프로그래머가되기를 기대하고 있습니다. 즉, 제대로 수행 할 수있을 때까지 요구 사항을 다운 그레이드해야 할 수도 있습니다.

아마도 OO가 최선의 해결책이 아니라는 위의 응답을 두 번째로 언급하면 ​​클라이언트가 포인트를 가질 수 있습니다.

질문 http://aichallenge.org 에서 자세하게 설명 된 AI 챌린지를보고 http://aichallenge.org 에서 다양한 스타터 패키지를 살펴보십시오-http: //aichallenge.org/starter_packages.php/ most OO 패러다임 내에 배치하지 않을 언어입니다.

프로그래밍 언어에 대해 아무것도 쓰지 않았습니다. 프로그래밍 언어는 아마도 가장 중요한 것입니다. OOP와 함수형 프로그래밍의 차이점은 코드 구성 방식뿐만 아니라 언어 자체입니다. 동시성이 높은 경우 기능 언어 Erlang이 사용 중이며 Java (예 : Facebook 채팅에서 사용)와 비교하여 매우 유리합니다. 성능 문제로 인해 OOP 솔루션이 실패 할 수 있습니다.

클라이언트는 대학이므로 언어는 성능 / 구성 문제 일뿐 만 아니라 학생과의 교훈적인 연구 또는 자체 연구에 사용될 수 있습니다. 따라서 다른 패러다임을 선택하려는 '설득'고객은 여기에 해당되지 않습니다. 이것은 당신이 그 일을 다룰 수 있거나 할 수없는 것입니다 (따라서 그 프로젝트를 취해서는 안됩니다).

고객이 "점프"라고 답하면 대답은 다음과 같습니다. __ _ ?

나를 위해, 나는 그것이 합리적이라면 설득하려고 시도 할 것입니다 (새 프로젝트). 또한 10 년 된 VB6 앱을 가진 클라이언트가 있습니다. 때때로 업그레이드를합니다 ...

클라이언트를 약간 '비교적 조사'(대결하지 않은 방식으로) :

클라이언트는 실제로 OOP와 함수형 프로그래밍의 차이점을 알고 있습니까? 고객의 우려 / 요청이 합법적인가요?

'예'인 경우 : 자격이 있다면 원하는 것을하고 돈을 가져 가십시오. 자격이 없다면, 그들에게 말하고 어떻게해야할지 결정하게하십시오.

다른 : 거기 밖으로 하이 테일!

double dist(Point p1, Point p2) 
{
  //return distance
}

이 함수는 함수 외부에서 아무것도 읽거나 쓰지 않는 한 작동합니다. 함수가 클래스 변수에 닿으면 더 이상 "기능적"이 아닙니다. 기능적 스타일의 장점은 더 이상 상태가 변경되거나 유효하지 않은 버그가 없다는 것입니다. 많은 함수는 수학 공식 일뿐입니다. 간단히 말해서 기능 프로그래밍입니다.

BTW 기능 기반 스타일을 객체 기반 또는 지향적 디자인에 결합 할 수 있습니다. 예를 들어 두 "점"변수는 상태가있는 객체입니다. 그리고 기능은 여전히 ​​작동합니다! 예 !!