객체 지향 언어의 비 객체 지향 프로그래밍 [닫기]

최근에 객체 지향 프로그래밍 (Object Oriented Programming)을 사용하여 함수 덧셈, 뺄셈, 곱셈, 나눗셈 및 거듭 제곱으로 계산기를 만드는 작업이 할당되었습니다 . 이 작업을 성공적으로 완료했습니다. 그러나 나중에 객체 지향 기술 / 방법 을 사용하지 않고 전체 프로그램을 다시 프로그래밍했습니다 .

코드 길이가 상당히 줄었고 이해할 수있는 것으로 나타났습니다. 그래서 내 질문은 언제 객체 지향 프로그래밍을 사용해야합니까? 객체 지향 언어로 객체 지향이없는 프로그램을 생성해도 괜찮습니까? 친절하게 도와주세요.

추신 : 나는 절차 적 프로그래밍에 비해 객체 지향 프로그래밍의 장점을 여기에 묻지 않습니다.

C ++은 단지 OO 언어가 아니라 다중 패러다임 언어입니다. 따라서 OO 프로그래밍을 결정하거나 반대 할 수 있습니다. OO 기술을 사용하면 프로그램에 더 많은 구조가 추가되므로 프로그램이 특정 크기 나 복잡성에 도달하면 도움이됩니다. 그러나이 추가 구조는 추가 코드 라인 가격에 제공됩니다. 따라서 "작은"프로그램의 경우 가장 좋은 방법은 종종 비 OO 스타일로 먼저 구현하고 나중에 수년에 걸쳐 프로그램이 성장하기 시작할 때 점점 더 많은 OO 기술을 추가하는 것입니다. "프로그램이지만 많은 비즈니스 프로그램의 일반적인 수명주기입니다).

까다로운 부분은 프로그램의 복잡성이 더 많은 구조를 요구하는 크기에 도달하는 시점을 놓치지 않는 것입니다. 그렇지 않으면 거대한 스파게티 코드가 생깁니다.

전문 프로그래머는 OOP를받을 것인지 아닌지를 어떻게 판단합니까? 정말 도움이 될 것입니다.

저에게는 두 가지 결정 사항이 있습니다. 첫째, 때로는 처음에 분명해질 것입니다. 구현 세부 사항에서 크게 다른 공통 방법을 공유하는 유사한 유형이 많이 있습니다. 예를 들어, 워크 플로 시스템을 구축하고 있었고 임의의 작업을 구현할 수있는 기능이 필요했습니다. 작업을 실행하기 위해 Execute()추상 메서드를 사용하여 각 작업에서 상속받은 기본 클래스를 구현했습니다 . 상속 클래스가 구현을 제공했지만 워크 플로 시스템은 어떤 종류의 작업이 실행되고 있는지 전혀 몰라도 실행을 시작할 수 있습니다.

그러나 대부분의 프로젝트는 명확하지 않습니다. 두 번째 결정 지점은 프로젝트의 하위 집합이 if-then 문 또는 스위치 케이스 문으로 인해 복잡해 졌을 때, 특히 if-then 문이 올바르게 실행 되려면 많은 설정 코드가 필요한 경우입니다. 나는 내가 성취하려고하는 논리를 잃어 가고 있다고 느끼고 코드는 깨지기 시작합니다. 이 시점에서 일반적으로 특정 구현을 사용하여 코드를 기본 클래스로 리팩토링 할시기라는 신호입니다.

기능적 스타일과 달리 객체 지향 스타일로 전환하는 데있어 중요한 부분은 if-then 문을 "이 작업 실행"문으로 변환하는 것입니다. 방대한 if-then 문 대신, 코드에 동작을 실행하도록 지시하면됩니다. 실제로 실행되는 조치는 제공 한 구현에 따라 다릅니다.

예를 들어 C # 스타일 의사 코드의 기능 스타일은 다음과 같습니다.

if ( action == "email" ) { 
    callEmailFunction(userInfo);
}
else if ( action == "sms" ) { 
    callSmsFunction(userInfo);
}
else if ( action == "web" ) { 
    endpoint = "http://127.0.0.1/confirm";
    confirmWeb(endpoint, userinfo);
} 
...

그러나 아마도 다음과 같이 다시 작성할 수 있습니다.

interface IConfirmable {
    void Confirm(UserInfo userinfo);
}

public class ConfirmEmail : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmSms : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmWeb : IConfirmable { 
    // this is a constructor
    public ConfirmWeb(string endpoint) { 
        ...
    }

    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via web
    }
} 

그런 다음 코드 자체 :

// An implementation that decides which implementation of the base class to use
// This replaces the if-then statements in the functional programmming.
IConfirmable confirmer = ConfirmerFactory.GetConfirmer();

// get the userinfo however you get it, 
// which would be the same way you get it in the functional example.
UserInfo userinfo = ...;

// perform the action.
confirmer.Confirm(userinfo);

이제 if-then 내부에 코드가 거의 없으면 이점이없는 많은 작업처럼 보입니다. 그리고 if-then에 코드가 거의 없을 때 맞습니다. 이해하기 어려운 코드에는 많은 작업이 필요합니다.

그러나 객체 지향 스타일은 Confirm()수행해야 할 방법 보다 여러 작업이있을 때 실제로 빛납니다 . 초기화 루틴, 실행할 수있는 3 개 이상의 액션 메소드 및 메소드가있을 수 있습니다 Cleanup(). 기본 알고리즘은 공통 기본 클래스를 구현하는 적절한 객체를 호출한다는 점을 제외하면 동일합니다. 이제 객체 지향 스타일에 실질적인 이점이 있습니다. 기본 알고리즘은 모든 단계에서 if-then 문을 확인하는 것보다 훨씬 읽기 쉽습니다.

예, 프로젝트의 범위가 잘 알려져 있거나 제한되어있는 경우 이전 스타일 코드를 사용하는 것이 정상입니다. 프로그램 또는 프로젝트를 확장 할 계획이라면 OOP를 사용하는 것이 좋습니다. 코드를 계획하고 원활하게 확장 할 계획이 없다면 코드를 매끄럽게 유지하고 확장 할 수 있기 때문입니다. OOP없이 코드를 작성하면 충분합니다. 비 OOP 접근 방식을 사용한다고해서 프로젝트를 업그레이드 할 수는 없지만 지루한 일이 될 것입니다. OOP는 우리가 다른 것보다 더 잘 이해하기 때문에 실제 생명체 인 것처럼 개념을 시각화하는 데 도움이됩니다.