아마도 객체 지향 패러다임을 사용하는 가장 큰 가능성은 코드 재사용 일 것입니다. 이것이 달성되었다는 일부 논쟁. 왜 달성되지 않았습니까?

OOP가 코드를 정의한대로 코드를 재사용하여 프로젝트의 생산성을 높일 수 있습니까?

아니면 더 관리하기 쉬운가? 아니면 유지 보수가 더 쉬워? 아니면 더 많은 품질로?

아마도 우리는 코드 재사용이 좋은 것이라는 데 모두 동의하지만이 목표를 달성하기위한 몇 가지 방법이 있습니다. 문제는 OOP가 제공하는 코드 재사용 방법에 관한 것입니다. 좋은가요? 객체 지향, 서브 클래 싱, 다형성 등 코드 재사용을위한 더 나은 방법이 있습니까? 어떤 방법이 더 낫습니까? 왜 ?

OOP 재사용 또는 다른 패러다임 재사용 경험을 알려주십시오.

코드 재사용은 좋은 생각입니다. 대단하지 않습니다 .

저는 약 30 년의 소프트웨어 엔지니어링에서 "재사용"하려는 관점을 가지고 있습니다.

나는 70 년대 초에 내가 만든 하나의 OS 디자인과 70 년대 후반에 내가 만든 다른 OS의 디자인을 재사용했다는 것을 알게 된 후 80 년대에 연구 주제로 "코드 재사용"을 조사하기 시작했다.

코드 재사용의 좋은 부분은 신의 정직한 코드를 가끔 재사용 할 수 있다는 것입니다. 그러나 세상은 코드 로 가득 합니다. 원하는 것을 어떻게 찾을 수 있습니까? 다음은 재사용 저주 라고 부르는 것입니다 .

저는 산타 클로스 (오픈 소스)이고 10 억 개의 소프트웨어 구성 요소가 있습니다. 당신은 그들 중 하나를 가질 수 있습니다.

행운을 빕니다.

재사용 문제를 잘 해결하려면 다음을 수행하십시오.

• Reuser는 자신이 필요로하는 기능 (기능, 성능, 대상 언어, 환경 가정 등)을 어떻게 든 지정해야합니다.
• 이러한 잠재적 기준에 의해 다양한 방법으로 색인화 된 "재사용 가능한"코드 라이브러리가 있어야합니다.
• 후보 요소를 선택하려면 몇 가지 메커니즘이 있어야합니다 (10 억 요소에서 모든 요소를 ​​개인적으로 볼 수는 없음)
• 선택한 후보가 사양에서 얼마나 멀리 떨어져 있는지 특성화하는 방법이 필요합니다.
• 재사용자가 선택한 재사용 가능한 코드를 수정할 수 있도록하는 일부 정규 프로세스가 있어야합니다 (여기서는 OOP의 가장 큰 기여 : 슬롯을 재정 의하여 기존 구성 요소 / 객체를 편집 할 수 있습니다. OOP는 다른 도움말을 제공하지 않습니다).
• 이 모든 것은 단순히 그것을 코딩하는 것보다 분명히 저렴해야합니다.

수년에 걸쳐 발견 된 것은 코드를 재사용 할 수있게하기 위해, 그 목적을 위해 설계되어야하거나, 너무 많은 암시 적 가정을 포함하고 있다는 것입니다. 가장 성공적인 코드 재사용 라이브러리는 실제로 매우 작습니다. 틀림없이 라이브러리와 프레임 워크는 "재사용 가능한"코드이며 매우 성공적입니다. Java와 C #은 꽤 좋은 컴퓨터 언어가 아니라 잘 설계되고 구현되며 문서화 된 라이브러리를 사용할 수 있기 때문에 성공합니다. 그러나 사람들은 라이브러리에서 소스 코드를 보지 않습니다. 그들은 잘 문서화 된 API를 호출합니다 (일반적으로 사용 가능하도록 설계되었습니다).

코드 재사용이 수행되지 않은 것 (OOP 모두)은 시스템 코딩 능력이 크게 향상되었습니다.

핵심 결점은 코드에 너무 많은 가정이 내장되어 있기 때문에 모든 종류의 코드 재사용이 근본적으로 제한되어 있다는 것입니다 . 코드를 작게 만들면 가정을 최소화 할 수 있지만 처음부터 구축하는 데 드는 비용이 크지 않으며 재사용 이익이 효과적이지 않습니다. 코드 청크를 크게 만들면 새로운 컨텍스트에서 거의 쓸모가 없습니다. 걸리버처럼, 그들은 백만 개의 작은 끈으로 해변에 묶여 있으며, 당신은 그것들을 모두 잘라낼 여유가 없습니다.

우리가 작업해야 할 것은 코드를 구성하기 위해 지식을 재사용하는 것입니다 . 이 작업을 수행 할 수 있으면 현재의 일련의 가정을 처리하면서 필요한 지식을 적용하여 필요한 코드를 구성 할 수 있습니다.

이렇게하려면 소프트웨어 구성 요소를 특성화하는 데 여전히 동일한 사양 기능이 필요합니다 (원하는 것을 말해야합니다!). 그러나이 "구성"지식을 스펙에 적용 하여 원하는 코드 를 생성 하십시오.

커뮤니티로서 우리는 아직 잘하지 못합니다. 그러나 사람들은 항상 그렇게합니다. 왜 자동화 할 수 없습니까? 많은 연구가 있으며, 이것은 많은 상황에서 수행 될 수 있음을 보여줍니다.

여기에 필요한 주요 기계 중 하나는 "구성 요소 설명"(이는 공식 문서 일 뿐이며 프로그래밍 언어처럼 구문 분석 할 수 있음)을 수용하고 프로그램 변환 을 적용하기위한 기계 도구입니다 .

컴파일러는 이미 이것을 수행합니다 :-} 그리고 그들은 그들이 다루는 문제의 클래스에 정말로 능숙합니다.

코드 생성 기능이있는 UML 모델이이 시도 중 하나입니다. 아주 좋은 시도는 아닙니다. 대부분의 UML 모델에서 말하는 것은 "이것과 같은 데이터가 있습니다"입니다. 기능이 빠진 경우 실제 프로그램을 생성하기가 매우 어렵습니다.

실용적인 프로그램 변환 시스템 인 DMS 도구 를 구축하려고합니다 . 코드를 생성하기 위해 사양을 추상화하는 것이 아니라 코드를 정리하는 레거시 코드에 프로그램 변환을 적용함으로써 상당히 산만 해졌습니다. (이것들은 초록에서 같은 문제입니다!). (이러한 도구를 만드는 데 많은 시간이 소요됩니다. 15 년 동안 그리고 그 동안 먹어야 만했습니다.)

그러나 DMS에는 위에서 설명한 두 가지 주요 속성, 즉 임의의 공식 사양을 처리하는 기능과 "코드 생성 지식"을 변환으로 캡처하여 필요에 따라 적용하는 기능이 있습니다. 놀랍게도, 우리는 특별한 경우에, 사양에서 다소 흥미로운 코드를 생성합니다. DMS는 구현을 생성하기 위해 자체적으로 사용됩니다. 그것은 (지식) 재사용이라는 약속의 적어도 일부를 달성했습니다 : 매우 중요한 생산성 향상. 약 7 명의 기술 인력으로 구성된 팀이 있습니다. DMS에 대해 1-2 MSLOC의 "사양"을 작성했지만 10MSLOC의 생성 된 코드가 있습니다.

요약 : 생성 지식의 재사용은 코드의 재사용이 아닌 승리 입니다.

코드 재사용은 OOP에서 달성되지만 기능 프로그래밍에서도 달성됩니다. 코드 블록을 가져 와서 코드의 나머지 부분에서 호출 가능하게하여 다른 곳에서이 기능을 사용할 수 있도록 코드 재사용이 가능합니다.

이 유형의 코드 재사용은 호출 가능한 블록을 변경하면 호출되는 모든 위치가 변경되므로 코드를보다 관리하기 쉽게 만듭니다. 이 결과는 품질과 가독성이 향상되었다고 말합니다.

코드 재사용을 제공하기 위해 OOP가 있는지 확실하지 않습니다. 객체와 상호 작용하고 데이터 구조의 세부 사항을 추상화하는 방법으로 OOP를 봅니다.

Wikpedia에서 :

객체 지향 프로그래밍에는 1960 년대까지 추적 될 수있는 뿌리가 있습니다. 하드웨어와 소프트웨어가 점점 복잡 해짐에 따라 관리 효율성이 종종 문제가되었습니다. 연구원들은 불연속적이고 재사용 가능한 프로그래밍 로직 단위를 강조함으로써 일반적인 문제를 해결하기 위해 소프트웨어 품질을 유지하는 방법과 객체 지향 프로그래밍을 부분적으로 개발했습니다 [인용 필요]. 이 기술은 자급 자족 모듈 ( "클래스")로 구성된 프로그램을 사용하여 프로세스보다는 데이터에 중점을 둡니다. 각 인스턴스 ( "개체")는 자체 데이터 구조 ( "멤버")를 조작하는 데 필요한 모든 정보를 포함합니다. 이는 수년 동안 지배적 인 기존 모듈 형 프로그래밍과는 달리, 데이터보다는 모듈의 기능에 초점을 맞추었지만 코드 재사용에도 동일하게 제공됩니다. 자체적으로 재사용 가능한 프로그래밍 로직 단위로 연결된 모듈 (서브 루틴)을 사용하여 협업 할 수 있습니다. 여전히 지속되는 이보다 일반적인 접근 방식은 데이터와 동작을 개별적으로 고려하는 경향이 있습니다.

예, 아니오

코드 재사용은 다양한 활동을위한 포괄적 인 용어입니다.

1. 단일 프로젝트 내에서 코드 재사용. OO는이를 위해 완벽하게 적합하며, 잘 설계된 응용 프로그램은 모델링 된 세계의 관계를 밀접하게 매핑하여 가능한 한 중복 코드를 제거하는 것이 좋습니다. 그러나 사전 OO 기술이 동일한 것을 달성 할 수 있다고 주장 할 수 있지만, OO는 여러 가지면에서 더 편리합니다.
2. 타사 라이브러리 이것은 OO와 함께 또는 OO없이 똑같이 잘 작동하는 것 같습니다.
3. 다목적 코드 재사용 OO의 가장 큰 코드 재사용 약속은 한 응용 프로그램 용으로 작성된 코드가 나중에 다른 응용 프로그램 용으로 재사용 될 수 있다는 것입니다.이 코드는 특별히 설계되지 않았습니다. OO의 개념이 고위 관리 사무소의 문을 통해 걸러지고 OO가 완전히 그것을 달성하지 못한 것은 모든 분노였습니다. 그 목적은 OO 디자인 (그리고 모든 절차 코드이지만 아마도 내 이론 일 뿐임)의 결정적인 측면이며, 코드 재구매 시도는 유지 보수 재난으로 끝났다는 것이 밝혀졌습니다. (오래된 프레임 워크의 잘 알려진 반 패턴은 누구도 수정하지 않아도되며 그 친구 인 약간 다른 프레임 워크-모든 앱은 일반적으로 여기에서 유래합니다.)

나는 긴 대답을 게시하지만 왜? Udi Dahan은 내가 할 수있는 것보다 훨씬 잘 설명합니다.

http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

다음은 게시물의 시작입니다.

이 산업은 재사용으로 미리 채워져 있습니다.

우리가 더 많은 코드를 재사용하면 모든 것이 더 나을 것이라는 믿음이 있습니다.

어떤 사람들은 객체 지향의 전체 지점이 재사용되었다고 말하는 데까지갔습니다. 캡슐화가 큰 것은 아니 었습니다. 그 구성 요소 지향 후에는 재사용이 이루어져야했습니다. 분명히 우리는 이제 서비스 지향에 대한 재사용 희망을 고정시키고 있기 때문에 그렇게 잘 전개되지 않았습니다.

오리엔테이션으로 재사용 할 수있는 방법에 대한 모든 패턴의 책이 쓰여졌습니다. 서비스는 엔티티 서비스 및 활동 서비스에서 프로세스 서비스 및 오케스트레이션 서비스를 통해이를 달성하기 위해 모든 방식으로 분류되었습니다. 작성 서비스는 재사용 및 재사용 가능한 서비스 작성의 핵심으로 선전되었습니다.

더러운 작은 비밀을 알려줄 수도 있습니다.

재사용은 오류입니다

저는 Chris에게 동의합니다. 함수형 프로그래밍은 코드를 재사용하는 좋은 방법입니다.

많은 프로그램에는 반복되는 코드 구조가 있습니다. 이를 위해 일부 디자인 패턴 이 OOP 세계에서 사용되지만 이는 재귀 함수 와 함수형 프로그래밍 언어의 패턴 일치 를 통해 달성 될 수 있습니다 . 이에 대한 자세한 내용은 실제 기능 프로그래밍 의 첫 번째 장을 참조하십시오 .

OOP의 깊은 상속은 많은 경우 오해의 소지가 있다고 생각합니다. 클래스가 있으며 밀접하게 관련된 많은 메소드가 다른 파일로 구현됩니다. Joe Armstrong 은 OOP에 대해 다음과 같이 말했습니다.

객체 지향 언어의 문제점은 이러한 암시 적 환경을 가지고 있다는 것입니다. 바나나를 원했지만 바나나와 정글 전체를 들고있는 고릴라였습니다.

고차 함수 는 코드 재사용 map과 관련하여 매우 유용 하며 foldr이는 Google의 MapReduce 의 기초입니다 .

비동기 메시지 전달 은 복잡한 소프트웨어를 구성하는 좋은 방법이며 일부 컴퓨터 과학자들은 개체가 Tell과 같이 비동기 적으로 서로 통신하는 것으로 가정한다고 OOP 원칙을 묻지 않습니다 . 이에 대한 자세한 내용은 객체 지향 프로그래밍 : 잘못된 경로? 있었다 조 암스트롱은 인용 :

나는 객체 지향 프로그래밍이 무엇인지 궁금해하기 시작했고 Erlang이 객체 지향이 아니라고 생각했는데 기능 프로그래밍 언어였습니다. 그런 다음 제 논문 감독관은 "그러나 당신은 틀 렸습니다. Erlang은 매우 객체 지향적입니다"라고 말했습니다. 그는 객체 지향 언어는 객체 지향이 아니라고 말했다. 나는이 믿거 나 말거나 경우 아주 확실하지 않다하지만 나는 생각하지만, 객체 지향 프로그래밍의 3 개 원칙은이 기반으로하는 것이 있기 때문에 얼랑 유일한 객체 지향 언어가 될 수있는 메시지 전달 당신이 가진 것을, 분리 객체 사이를 이 다형성을 .

이벤트 중심 시스템 및 Erlang에서와 같이 비동기 메시지가 전달되는 것도 시스템을 분리하는 매우 좋은 방법 이며 복잡한 시스템에서는 느슨한 결합 이 중요합니다. 충분히 분리 된 시스템을 사용하면 시스템이 실행되는 동안 다른 노드에서 시스템을 발전시킬 수 있습니다. Unibet은 이에 대해 훌륭한 프레젠테이션을했습니다 : 도메인 이벤트 중심 아키텍처

그러나 대부분의 코드 재사용은 라이브러리와 프레임 워크를 사용하여 수행된다고 생각합니다.

겸손한 유닉스 파이프는 다른 어떤 것보다 코드 재사용을 위해 더 많은 일을 해왔습니다. 객체는 코드가 등장 할 때 직관적으로 코드를 구성하는 방식이되었고 나중에 사람들은 무엇이든 모든 것을 다루기 시작했습니다. 일반적으로 객체는 코드 재사용이 아닌 캡슐화를위한 것이며, 코드 재사용에는 더 많은 것이 필요하며 클래스 상속 계층 구조는 코드 재사용 메커니즘이 실제로 해야하는 것을 대체하지 못합니다.

OOP는 특별하지 않습니다. OOP 유무에 관계없이 재사용 가능한 코드를 만들 수 있습니다. 순수한 기능은 특히 재사용이 가능합니다 . 예를 들어, java.lang.math.sqrt(double)숫자를 가져 와서 숫자를줍니다. OOP는 없지만 대부분의 코드보다 재사용이 가능합니다.

기능적 프로그래밍 관점에서 OOP는 주로 상태 관리에 관한 것입니다.

함수형 프로그래밍에서는 목록에 유용한 수백 가지 유용한 함수를 쉽게 사용할 수 있습니다. http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Data-List.html .

List 클래스에 수백 개의 메소드가 있습니까? 공용 메소드는 작게 유지하려는 내부 상태에 대한 인터페이스로 간주됩니다.

안타깝게도 많은 작은 기능을 다시 사용하는 대신 일부 사람들은 기능을 복제합니다. 나에게 그것은 OOP 가 함수형 프로그래밍만큼 코드 재사용 을 장려하지 않기 때문 입니다.

나를 위해, 그래도, 항상 그런 것은 아니며, 다른 방법으로도 가능했을 것입니다.

대부분의 경우 추상 기본 클래스를 만들고 해당 클래스의 구체적인 구현을 만듭니다.

또한 많은 프레임 워크가 코드 재사용을 제공하기 위해 상속을 사용합니다 (Delphi, Java, .Net은 즉시 떠오르는 일부입니다).

그것은 많은 유틸리티 라이브러리와 코드 스 니펫이 그 일을 할 수는 없었지만 잘 설계된 객체 계층에 대해 기쁘게 생각합니다.

내 경험상, 상속 계층과 같은 OOP 원칙을 사용했던 것보다 일반적인 프로그래밍 기능 (C ++ 템플릿과 같은)을 통해 "재사용 가능한"코드를 활용하는 데 더 많은 성공을 거두었습니다.

효과적인 재사용을 위해 OOP가 너무 열려 있습니다.

재사용 할 방법이 너무 많습니다. 각 공과 반은 "나의 새로운 인스턴스를 만들어라!"라고 묻습니다. 각 공공 방법은 말한다 : "전화!" , 각 보호 된 방법은 "나보다 우선합니다!" -이 모든 재사용 방법은 서로 다릅니다. 매개 변수 가 다르고 , 상황에 따라 다르며, 규칙이 다릅니다. 호출 / 확장 / 재정의 방법.

API 가 더 낫습니다. OOP (또는 비 oop) 포인트의 엄격한 하위 집합이지만 실제로는 API가 과장되고 지속적으로 성장하고 있지만 여전히 많은 연결 지점이 있습니다. 또한 좋은 API는 삶을 더 쉽게 만들 수 있으며 OOP에 인터페이스를 제공하는 가장 좋은 방법입니다.

Datadlow 패러다임 은 구성 요소에 대한 엄격한 인터페이스를 제공하며 다음 유형의 포트가 있습니다.

• 소비자 (입력) 및
• 생산자 (출력).

도메인에 따라 일부 패킷 유형이 있으므로 소비자와 생산자는 동일한 (또는 호환되는) 포트를 가지고 연결할 수 있습니다. 연결에서 매개 변수 또는 조정이 없기 때문에 실제로 소비자와 생산자를 연결하기 때문에 시각적으로 수행 할 수있는 가장 아름다운 부분입니다.

약간 불분명했습니다 .StackOverflow의 "dataflow"태그 또는 Wikipedia "datafow programming" 또는 Wikipedia "flow-based programming"을 볼 수 있습니다.

(또한 C ++로 데이터 흐름 시스템을 작성했습니다. 따라서 OOP와 DF는 적이 아니며 DF는 높은 수준의 조직 방식입니다.)

CommonLisp에는 재사용을위한 많은 방법이 있습니다.

• 기본적으로 코드가 일반적인 동적 입력

• 명령 적 추상화, 즉 서브 루틴

• 다중 상속 및 다중 디스패치가있는 객체 지향

• 구문 요약, 새로운 구문 구조를 정의하거나 보일러 플레이트 코드를 줄여주는 기능

• 기능적 추상화, 클로저 및 고차 함수

당신이 다른 언어에 커먼 리스프의 경험을 비교하려고하면 당신은 코드 재사용을 용이하게 주요 기능의 존재 인 것을 볼 수 있습니다 모두 객체 지향 및 기능 추상화. 그것들은 대안보다 보완 적입니다. 그중 하나가 없으면 누락 된 기능을 서투른 방식으로 다시 구현해야합니다. 예를 들어 확장 불가능한 메소드 디스패치를 ​​얻기 위해 클로저 및 패턴 일치로 사용되는 functor 클래스를 참조하십시오.

사람들이 그것을 묘사하는 방식을 "재사용"하는 것은 실제로 없습니다. 재사용은 우발적 인 재산입니다. 계획하기가 어렵습니다. "재사용"에 대해 이야기 할 때 대부분의 사람들이 의미하는 것은 "사용"입니다. 훨씬 덜 매력적이고 흥미로운 용어입니다. 라이브러리를 사용할 때는 일반적으로 라이브러리를 원래 용도로 사용합니다. 당신은되어 있지 당신이 정말 미친 일을하지 않는 한 그것을 재사용.

그런 의미에서, 현실 세계에서의 재사용은 사물을 재활용하는 것입니다. 나는이 좌석을 여기에서 재사용하고 침대를 형성하기 위해 재 배열 할 수 있습니다! 매우 편안한 침대는 아니지만 그렇게 할 수 있습니다. 그것은 그들의 주된 용도가 아닙니다. 원래 적용 가능한 영역 외부에서 재사용하고 있습니다. [...] 내일, 나는 영국으로 돌아갈 것이다. 나는 비행기를 재사용 하지 않을 것이다 . 나는 그것을 의도 된 목적으로 만 사용할 것입니다. 그에 대한 환상이나 흥미 진진한 것은 없습니다.

— 케 블린 헤니

조롱하고 고백 할 위험이 있습니다. 최근에는 OOP 만 사용했습니다. 자동으로 나에게 오지 않습니다. 내 경험의 대부분은 관계형 데이터베이스와 관련이 있으므로 테이블과 조인을 생각합니다. 프로그래밍과 관련하여 생각을 다시 연결할 필요가 없도록 처음부터 배우는 것이 낫다는 주장이 있습니다. 나는 그 사치가 없으며 상아탑 이론에 대한 내 경력을 망치지 않습니다. 다른 모든 것들과 마찬가지로, 알아낼 것입니다.

처음에는 전체 개념이 이해가되지 않는다고 생각했습니다. 그것은 불필요하고 너무 많은 문제로 보였습니다. 나는 이것이 미친 이야기입니다. 분명히 더 나은 방법을 위해 무엇인가의 이점을 이해하거나 무시하기 전에 어느 정도의 이해가 필요합니다.

코드 재사용은 코드를 반복하지 않으려는 의지, 코드 수행 방법에 대한 이해, 사전 계획을 필요로합니다. 가치가없는 경우가 있다고 결정했을 때 코드 재사용을 피해야합니까? 그리고 다른 언어에서 코드를 상속 받았다고 생각할 때 오류가 발생할 정도로 언어가 너무 엄격하지 않습니다. 기껏해야이를 구현하는 데 도움이되는 환경을 제공합니다.

OOP의 가장 큰 장점은 코드 구성 방법에 대한 일반적인 수용입니다. 다른 모든 것은 그레이비입니다. 프로그래머 팀은 모든 클래스가 어떻게 구성되어야하는지에 완전히 동의하지는 않지만 코드를 찾을 수 있어야합니다.

나는 그것이 어디에나있을 수 있다는 것을 알기에 충분한 절차 적 코드를 보았습니다.

OOP는 더 많은 코드 재사용 방법을 제공합니다 . 그게 다야

수평 재사용 : 측면, 특성, 이식

Classic OO는 때로는 코드 재사용에 부족합니다. 특히 클래스 간 실제 기능을 공유하는 더 좋은 방법이 없기 때문에 모든 상속을 미치게 할 때 특히 그렇습니다. 이 문제에 대해 AOP, 특성 및 이식편과 같은 수평 재사용 메커니즘이 만들어졌습니다.

Aspect 지향 프로그래밍

나는 AOP를 OOP의 누락 된 반 오렌지로 간주한다 AOP는 실제로 알려진 것이 아니지만 프로덕션 코드로 만들어졌습니다.

간단한 용어로 설명하려고 노력할 것입니다. aspect라는 특별한 구조로 기능을 주입하고 필터링 할 수 있다고 상상해보십시오.이 양상에는 리플렉션 을 통해 영향을받을 대상과 방법을 정의하는 "메소드"가 있지만 컴파일 타임에는 이 과정을 직조 라고 합니다.

예를 들어 "get으로 시작하는 특정 클래스의 모든 메소드에 대해, 프로그램은 얻은 데이터와 도착한 시간을 로그 파일에 기록합니다"라고 말하는 측면입니다.

AOP를 더 잘 이해하려면이 두 가지 대화를보십시오.

• Aspect 지향 프로그래밍을 사용하여 애플리케이션 공격 방지 1/6
• Aspect Oriented Programming : Gregor Kiczales (AOP의 주요 인물)의 모듈화 에 관한 급진적 연구

특성 및 이식

특성 은 OOP를 보완하는 재사용 가능한 코드를 정의하기위한 또 다른 구성 요소입니다 . 믹스 인과 유사 하지만 더 깨끗합니다.

그것들을 설명하는 대신, 둘 다 설명하는 훌륭한 PHP RFC가 있습니다 . 특성은 PHP btw에오고 있으며 이미 트렁크에 커밋되었습니다.

요약하자면

OOP는 여전히 모듈화의 핵심이며, 제 생각에는 OOP는 여전히 불완전 합니다.

OOP 도구 없이도 더 많은 장소에서 사용할 수있는 코드를 작성할 수있는 유용한 도구 세트를 제공합니다. PrintIt오래된 객체를 가져 와서 호출 하는 함수 를 작성하면 .toString()둘 이상의 객체 유형으로 호출하자마자 해당 코드를 다시 사용하게됩니다. 이러한 도구를 사용하면 각 코드 줄이 더 많은 일을합니다.

기능적 프로그래밍은 힙 스터들 사이에서 지금 매우 뜨겁습니다. 그것은을 제공합니다 전체 별도의 코드의 각 라인은 더 많은 일을 할 수 있도록 도구 세트. 아마도 나아지거나 작동하지 않지만 도구 상자에 다른 도구를 제공합니다.

(객체 지향 재사용의 추가 수준에 대한 미친 아이디어가있었습니다. 아이디어는 단일 Customer클래스를 정의하고 작성한 모든 응용 프로그램에서 사용할 수 있다는 것입니다. 그러면 응용 프로그램은 여기 저기에 약간의 접착제 일 것입니다. OO가 실패했거나 재사용이 실패한 것은 아닙니다. 응용 프로그램 내에서 기본 유형의 코드를 재사용하면 더 많은 응용 프로그램을 작성하고 더 빨리 작성할 수있었습니다.)

위의 게시물을 읽고 몇 가지 언급 :

• 많은 사람들이 OOP에서 코드 재사용이 상속을 의미한다고 생각합니다. 난 동의하지 않는다. 인터페이스와 계약은 OOP 시스템에서 코드 재사용의 핵심입니다. OOP는 컴포넌트 기술을 만드는 회색 상자입니다.
• 재사용의 주제로서 도메인 특정과 일반 "frameworks"의 차이점은 너무 추상적이라고 생각합니다. 사물에 대한 나의 견해에서, 구성 요소 (간결하고, 최소이며 재사용 가능한 인터페이스 계약과 그 뒤에 구현)는 그것이 해결하는 문제가 잘 이해 된 경우에만 수행 될 수 있습니다. 비 도메인 전문가가 도메인에 대한 지식이 부족한 상태에서 작업을 수행 할 수있게하는 도메인 별 구성 요소는 (재사용이 가능한) 구성 요소입니다. 사용자는 인터페이스를 이해해야하므로 문제 영역의 복잡성이 줄어 듭니다.
• 종종 재사용 레벨 : 아이디어 재사용, 사양 재사용, 아키텍처 / 디자인 재사용, 인터페이스 재사용, 테스트 케이스 재사용. 코드 재사용이 항상 유리한 것은 아닙니다. 그러나 새롭고 유사한 제품을 다루기 위해 특정 아키텍처를 고수하는 것은 종종 큰 시간 절약입니다.
• 내 눈에 OOP 디자인 패턴 (Gamma et al.)은 코드 재사용의 맥락에서 의미가있는 것이 아니라 전술적 구현 기술에 대해 자세히 설명했다. OOP 요소로 응용 프로그램을 작성하는 데 도움이되지만 단일 응용 프로그램 이외의 "코드 재사용"질문에 대한 솔루션으로 볼 수는 없습니다.
• 20 년의 C / C ++ / C # 경험과 6 개월 기능 프로그래밍 (F #)이 불공평 할 수도 있습니다. 재사용을 가능하게하는 한 가지 주요 요소는 다음과 같습니다. 사람들은 "인터페이스"를 쉽게 찾아서 연구하고 이해 한 다음 사용해야합니다. 순수한 함수형 프로그래밍으로 인해 구조, 재사용 후보자 또는 시작 위치 및 종료 위치를 쉽게 확인할 수 없습니다. 그렇게 칭찬 된 "구문 설탕"은 종종 내 눈에 소금이되어, 무슨 일이 일어 났는지 쉽게 알 수 없습니다. 따라서 나는 보이지 않는 부작용 (지연 평가, 모나드, ...)을 숨길 수있는 기능 (기능-무엇입니까?)을 재사용하려고 시도하지 않을 것입니다. 실수하지 말고, 함수형 프로그래밍에는 매우 멋진 측면이 있지만, 내가 주장한 모든 강점은 의심의 여지가 있습니다.
• 사양, 디자인, 구현은 결합되어 있지만 "같은 것"에 대해 쉽게 이해할 수있는 관점은 아닙니다. 새로운 프로그래밍 패러다임보다 미래의 생산성 향상을 위해 훨씬 더 중요한 것은, 이러한 관점 사이의 상호 이익을 증가 (자동 추론, 추적 성)하는 것입니다. 주석 처리없이 사양에 대한 인터페이스 및 계약의 검증을 지원하는 형식화 된 사양 언어, 표준화 된 테스트 표기법 (예 : ttcn3) 및 프로그래밍 언어가 가장 시급한 것입니다.

문제는 더 미묘합니다.

1. OOP는 변경 가능한 상태로 코드를 구성 하는 훌륭한 방법입니다 . 상태를 객체로 캡슐화함으로써 명령형 statefull 코드가 이해하기 쉬워집니다. 예를 들어, 상태 조각이 클래스의 개인 필드로 표현되는 경우 최소한이 특정 상태 조각은이 방법으로 만 수정할 수 있다는 것을 알기 때문에 수업. (그리고 상속을 남용함으로써이 이점을 쉽게 깨뜨릴 수있다.) 이것으로 충분하지만 이것조차 갖지 않는 것보다 낫다 .
2. 변경 가능한 상태의 코드는 본질적으로 재사용하기가 어렵습니다 . 불변의 데이터 구조를 사용하는 코드보다 훨씬 어렵습니다.

따라서 OOP 자체는 재사용 가능한 코드를 만드는 관점에서 나쁘지 않지만 , OOP를 사용하여 작성된 코드 종류는 본질적으로 재사용하기가 어렵습니다 .

또한 함수형 프로그래밍 은 재사용 가능한 코드를 생성 할 수 있습니다 . 그러나 마감 기한을 맞추면서 제정신 기능 코드를 작성할 수있는 추상화를 얻는 것은 불가능합니다. 그리고 "반-오른쪽"추상화는 OOP 스타일을 표현하기가 더 쉬울 것입니다. 코드 재사용 이 더 쉬워 지는 경향이 없습니다. 추상화 수준이 높을수록 코드 이해에는 프로그래머의 제한된인지 능력에 대한 선행 투자가 더 많이 필요합니다.

실제적인 예로서 : 게임 코드는 많은 변경 가능한 상태를 수반합니다 . 이는 게임이 매우 퍼즐 / 알고리즘이 아닌 한 게임 코딩에 대해 생각하는 자연스러운 방법이기 때문에 분명히 OO를 사용하여 구조화됩니다. 물론 재사용하기가 어렵습니다. 그러나 동일한 지식을 포함하는 동일한 코드 는 OOP없이 재사용하기가 훨씬 더 어려울 것 입니다. 그리고 그것을 기능적인 스타일로 재 작성하는 것은 그 코드에 대한 생각, 그 뒤에있는 지식을 완전히 바꿔야 할 수도 있습니다 . 그래, 그 결과 코드 뒤에 지식은 FP에 OO 어쩌면 다시 작성 후 더 명확하게 될 것이다 ...하지만 비용은 거대 할 수 있으며 수 있습니다당신이 끝내는 믿을 수 없을만큼 똑똑하고 잘 추상화 된 코드를 재사용하려는 사람들이 지불 해야하는 비용의 종류는 역설적으로 사람들은 기술적으로 더 재사용 가능하더라도 코드를 재사용하지 않을 것입니다.

... 마지막 미묘함을 초래합니다. 코드 재사용은 코드에만 국한된 것이 아니라 People | Code 인터페이스에 관한 것입니다. OOP는 요즘에 작성된 많은 종류의 코드에 대해 얼마나 많은 사람들이 생각하는지와 잘 어울리므로이 인터페이스를 제공하는 적절한 작업을 수행합니다. FP는 코드 재사용에 더 좋을지 모르지만 오늘날 사람들이 실제로 작성해야하는 코드 를 쉽게 재사용하는 것은 아닙니다 . 변경해야하는 코드 종류에 따라 변경됩니다.

추신 : 그리고 누군가가 "OO가 변경 가능한 상태에 관한 것이 아니라면, 변경 불가능한 상태의 OO를 가질 수도 있습니다."라고 말하고 싶습니다. 그것은 당신을 위해 일할 때 좋으며 일부 언어의 모듈 시스템의 단점을 피하고 더 재사용 가능한 코드를 초래할 수 있습니다. 그러나 그것은 OO가 아닙니다.)