절차 코드 대 OOP 코드

19

[Procedural Style]에서 13000+ 라인의 PHP로 프로젝트를 완료했습니다.

그러나 OOP로 변환해야합니까? [ 세계가 OOP로 바쁘기 때문에 ]

내 코드에는 OOP [캡슐화, 상속 기본적으로 ...] 기능이 필요하지 않습니다!

그래서 내가 무엇을해야하니?

그리고 OOP로 변환하면 어떤 도움을받을 수 있습니까?

programming-languages programming-practices

— 수 라브
소스

21

이 프로젝트를 변경해야 할 경우 알려주십시오. 이 결정을 내렸다거나 후회한다면 기뻐할 것입니다.

— JeffO

2

캡슐화가 필요합니다. OO는 그것을 얻는 한 가지 방법입니다. 어쩌면 당신에게 맞는 다른 것이 있지만 코드 종속성을 제어 해야하는 방법이 있습니다.

— Marcin

몇 년 전 저는 주로 JavaScript로 작성된 중간 크기의 웹 응용 프로그램에서 작업했습니다 (요청하지 않음). 코딩 스타일은 크게 절차 적이었습니다. 프로젝트가 거의 완성되자 코드 작성 방식에 불만이 생겼으며 OOP-JavaScript로 코드의 상당 부분을 다시 작성했습니다. 이로 인해 프로젝트 완료가 지연되고 나중에 프로젝트에서 유지 관리가 거의 이루어지지 않았습니다. 나는 항상 그 코딩의 모든 노력이 가치가 있는지 궁금해했다 ;-)

— Pandincus

예, 그만한 가치가있었습니다. 재사용의 문을 항상 열어 두어야합니다.

— Chani

1

문제는 다음과 같습니다. 추가 개발을 기대하십니까? 절차 적 프로그래밍은 필요한 것을 정확히 알고 변경되지 않을 때 가장 쉽고 빠른 방법입니다. 절차 적 코드를 변경하면 고통 스러울 것입니다. OOP에서는 훨씬 쉬울 것입니다.

— Kamil Tomšík

52

내 코드에는 OOP 기능이 필요하지 않습니다.

자신의 질문에 대답 했습니다.이 경우 OOP 가 필요하지 않고 프로젝트가 작동하면 변환하지 마십시오.

그러나 OOP를 사용하여 다음 프로젝트에 하는 것이 좋습니다.

적절한 위치에서 사용되는 한 절차 적 프로그래밍에는 본질적으로 잘못된 것이 없습니다.

— 크리스프
소스

2

+1 동의 : "다음 프로젝트에 OOP를 사용해야합니다".

— Cary Chow

11

+1 예, 제대로 작동하면 수정하지 마십시오.

— setzamora

4

지금 제대로 작동하면 변경하지 말고 다음 기능 요청이 무엇인지 알 수 없습니다.

— JeffO

7

"다음 프로젝트에 OOP를 사용하는 것을보아야합니다." 일부는 절차 적으로 작성하는 것이 좋으며 일부는 OOP에 더 적합합니다. 적절한 것을 사용하십시오.

— TMN

@TMN-암시 적-명시 적으로 작성해야합니다.

— ChrisF

16

아니요. OOP가 필요하지 않기 때문이 아닙니다.

프로그램이 이미 완료되어 만족스럽게 작동한다면 90 % 이상의 시간이 지나면 어떤 이유로 든 완성 된 코드를 다시 작성하는 것이 시간 낭비입니다.

OOP가 모두 강력하지는 않습니다. OOP를 사용해서는 안되는 곳이 많으므로 OOP가 트렌드이므로 사용하지 마십시오.

— 스키 키
소스

1

"완료된 코드"란 작동한다는 의미입니까?

— JeffO

@eff O 네 선생님! 그것은 완벽하다 :)

— Sourav

그는 프로젝트를 마치고 완벽하게 진행되고 있다고 말했다. 나에게 이것은 고객에게 배달 할 준비가되었거나 고객이 있다고 가정하여 고객에게 배달되었음을 의미합니다. 완료되면 테스트를 거쳐 출하 할 준비가되었음을 의미합니다. 물론 주요 버그가 다시 나타나면 재 작성이 시작될 수 있습니다.

— Skeith

"OOP를 사용하지 않아야하는 많은 장소"에 대해 자세히 설명하십시오.

— 팔콘

3

@Falcon은 OOP 코드가 아무리 잘 설계되어 있더라도 문제 도메인 자체가 OO 모델에 제대로 매핑되지 않으면 OOP 디자인이 엉망입니다. OOP로 표현해서는 안되는 많은 문제 도메인이 있습니다 .

— SK-logic

8

저의 일반적인 패러다임은 무엇입니까? (그리고 왜 세 가지 주요 패러다임 중 어느 것도 올바른 방법이나 잘못된 프로그래밍 방법이 아닙니다) :

절차 적 프로그래밍은 높은 수준에서 간단한 문제 (낮은 수준에서는 복잡 할 수 있음)가 있고 그에 따라 간단한 선형 코드를 작성하려는 경우에 좋습니다. 문제가 어디서나 강력한 디커플링이 필요하지 않은 경우 OO보다 쓰기 쉽고 이해하기 쉽고 기능적입니다. 예 : OO 또는 기능을 사용하여 문제를 해결하면 숫자 코드, 가장 작은 스크립, 가장 작은 하위 문제가 있습니다.

객체 지향 코드는 우려 사항을 두 개 이상 구현할 수 있으므로 우려 사항을 강력하게 분리해야 할 때 유용합니다. 예 : 대부분의 대기업 소프트웨어. 예를 들어 비즈니스 로직을 독립적으로 변경해야하므로 비즈니스 로직과 프리젠 테이션 로직을 강력하게 분리하려고 할 수 있습니다.

기능적 프로그래밍은 정책에서 메커니즘을 강력하게 분리해야 할 때 유용합니다. 정책 기능을 허용하는 메커니즘 기능을 갖는 것은 좋은 패턴입니다. (D 프로그래밍 언어의 std.algorithm 모듈을 살펴보면서 그것에 대해 배웠습니다 .) 정책과 메커니즘 코드 사이의 경계에서 변경 가능한 상태를 추상화하면 일반적으로 API를 추론하기가 더 쉽습니다. 변경 가능한 상태가 어느 쪽이든 개인적으로 사용되는 경우 구현 세부 사항입니다. 함수형 프로그래밍의 다른 강점은 자명 한 이유 때문에 동시성입니다.

— 딤차
소스

각 유형의 프로그래밍 패러다임을 설명하고 사용시기 / 방법에 대한 예를 제공하는 훌륭한 답변에 감사드립니다.

— 케빈 페노

7

코드에는 "OPP가 필요하지 않습니다". 프로그래머는 다른 모드에서 생각할 수있는 한,이 문제 나 그 특정 문제가 $ PARADIGM을 "필요"하거나 그러한 방식으로 해결하는 것이 가장 좋다고 생각합니다.

하나의 패러다임을 아는 프로그래머가 자신의 패러다임이 가장 크다고 생각하는 경우가 종종 있습니다. 하나의 크기는 모두에게 적합하며, 현재 또는 유행이라면 Procrustes의 침대에서 자야합니다.

— 잉고
소스

5

OOP가 필요하다는 명확한 징후가있는 경우에만 프로젝트를 OOP로 변환해야합니다. 이러한 상황이 발생할 수있는 시나리오는 다음과 같습니다.

프로젝트 확장
팀에 더 많은 개발자 추가

이러한 시나리오에서도 프로젝트를 OOP로 변환하지 않아도됩니다.

— 디모데 그 로테
소스

좋은 지적이지만, 절차 적 코드 인 경우 프로젝트를 확장하거나 팀에 개발자를 추가하는 것이 왜 문제가 될 수 있는지 말해 줄 수 있습니까?

— Sourav

프로젝트를 확장하려면 복잡한 관계형 구조를 응용 프로그램 모델에 추가해야 할 수 있습니다.이 경우 OOP로 전환하면 수익성이 높아질 수 있습니다. 응용 프로그램이 비트 단위로 확장되고 장기적으로 OOP에서 이해하기 쉽고 이해하기 쉬운 것으로 판명되면 새로운 개발자는 코드가 OOP 인 경우 더 빨리 '잡을'수 있습니다. 비 OO 코드의 레거시를 남기면 나중에 프로젝트가 커질 때 문제가 될 수 있습니다. '사물이 길을 가졌기 때문에 존재하는 방식'인 사례 중 하나 이상

— Timothy Groote

3

이것은 내가 질문을 읽을 때 내 마음에 온 것입니다. 그는 13K 줄의 코드를 작성했다고 말합니다. 한 번만 사용하면 낭비되지 않기를 바랍니다. 재사용해야한다면 oop는 필수 아이템이 될 것입니다. 그렇지 않으면 새로운 개발자에게는 악몽이 될 것입니다

— Chani

4

둘 다 좋을 수도 있고 둘 다 나쁠 수도 있습니다. 그러나 다른 하나처럼 보이도록 개조하는 것은 좋은 생각이 아닙니다.

— wen
소스

2

OO가 발명 된 이유를 다시 생각하면 OOP 가 전혀 필요 하지 않지만 때로는 인생을 훨씬 쉽게 만듭니다.

C 코딩 시대로 거슬러 올라가면 매우 큰 프로그램이 지저분 해지고 계속 작업하기가 어려워 질 수 있습니다. 그래서 그들은 그것을 모듈 식 덩어리로 나누는 방법을 발명했습니다. OOP는 이러한 접근 방식을 취해 더욱 모듈화하여 프로그램 논리를 통해 데이터를 나머지 코드와 더욱 분리시킵니다.

이를 통해 더 큰 프로그램을 작성할 수 있으며, 작업의 거대한 코끼리를 대신에 마우스 크기의 작업으로 100 개로 변경했습니다. 추가 된 보너스는 이러한 '마우스'중 일부를 다른 프로그램에서 재사용 할 수 있다는 것입니다.

물론, 실제 세계는 그렇게 다르지 않으며, 객체 재사용이 의도 한 방식에 따라 잡히지 않았지만 그것이 쓸모없는 패러다임을 의미하지는 않습니다.

쓸모없는 것은 코딩 스타일에 지나치게 의존하는 것입니다. 작고 중요하지 않은 수천 개의 클래스로 OO를 수행하는 사람은 실제로 제대로 수행하지 못하고 있습니다. 자신이나 다른 사람을 위해 유지 관리의 악몽을 만들고 있습니다. 3 가지 기능인 절차 적 응용 프로그램을 작성하는 사람은 인생을 어렵게 만듭니다. 가장 좋은 방법은 중대 규모의 대형 객체 (때때로 한 번 가려고했던 구성 요소라고도 함)로 재사용 가능한 훨씬 많은 독립형 코드 및 데이터를 제공 할 수 있습니다 나머지 앱과는 별도로

다음 번에 내 충고 : 일반적인 절차 코드를 작성하지만 기본 데이터 구조의 단일 객체를 만듭니다. 함수에서 데이터로 데이터를 전달하는 것보다 작업이 더 쉬운 방법을 찾으십시오.

— bj
소스

0

내 코드에는 OOP [캡슐화, 상속 기본적으로 ...] 기능이 필요하지 않습니다!

어떻게 알았어?

이 프로젝트를 유지해야합니까? 새로운 기능이 계획되어 있습니까? 당신과 함께 발전 할 다른 사람들이 있습니까? 너 스스로 반복 했니? 코드를 이해하기 어렵습니까?

대답이 "예"이면 OOP 스켈레톤 설정에 대해 생각하고 시작해야합니다.

— vihus
소스