왜 기본 기능보다 PHP OOP를 사용합니까?

왜 기본 기능보다 PHP OOP를 사용합니까?

---

이 문제에 대한 몇 가지 게시물이 있지만 객체 지향 코딩을 사용해야 할 때와 include에서 프로그래밍 함수를 사용해야 할 때를 명확하게 알지 못했습니다. 누군가 OOP가 실행하기에 매우 무겁고 더 많은 워크로드를 만든다고 언급했습니다. 이게 옳은 거니?

50 개의 함수가있는 큰 파일이 있다고 가정 해 보겠습니다. 수업에서 왜 이것을 부르고 싶습니까? 그리고 function_name ()이 아니라? 내 모든 기능을 보유하는 객체를 전환하고 만들어야합니까? 장점 또는 구체적인 차이점은 무엇입니까? PHP에서 OOP를 코딩하는 데 어떤 이점이 있습니까? 모듈화?

---

많은 시나리오에서 절차 적 프로그래밍은 괜찮습니다. OO를 사용하기 위해 사용하는 것은 쓸모가 없습니다. 특히 POD 개체 (일반 데이터) 로 끝날 경우에는 특히 그렇습니다 .

OO의 힘은 주로 상속과 다형성에서 비롯됩니다. 클래스를 사용하지만이 두 개념 중 하나를 사용하지 않는 경우 처음에 클래스를 사용할 필요는 없습니다.

OO가 빛나는 가장 멋진 장소 중 하나는 스위치 온 유형 코드를 제거 할 수 있다는 것입니다. 중히 여기다:

function drive($the_car){

    switch($the_car){

      case 'ferrari':
          $all_cars->run_ferrari_code();
          break;

      case 'mazerati':
          $all_cars->run_mazerati_code();
          break;

      case 'bentley':
          $all_cars->run_bentley_code();
          break;
    }
}

OO 대안으로 :

function drive($the_car){

    $the_car->drive();
}

다형성은 런타임 정보를 기반으로 적절한 유형의 "운전"이 발생하도록합니다.

---

다형성에 대한 참고 사항 :

두 번째 예제에는 몇 가지 전제가 있습니다. 즉, 모든 자동차 클래스가 추상 클래스 를 확장 하거나 인터페이스를 구현한다는 것 입니다.

둘 다 클래스를 확장하거나 구현하여 drive(). 이것은 drive()어떤 차를 운전하고 있는지 알 필요없이 모든 차에 접근 할 수있게 해주기 때문에 매우 강력합니다 . 그 이유는 drive()메서드를 포함하는 추상 클래스를 확장 하거나 drive()메서드가 정의되도록 하는 인터페이스를 구현 하기 때문입니다.

그러니 당신이 있는지 모든 특정 자동차 중 하나 추상 클래스를 확장하는 것을 확인으로 car또는 구현 인터페이스를 같은 canBeDriven(둘 다 있어야 선언drive() 방법) 그냥 호출 할 수 있습니다 drive()당신이 알고있는 객체에 대한 방법을 차다 (하지만 특정 자동차 클래스에서 해당 메소드를 정의 할 때까지 PHP가 치명적인 오류를 발생 시키므로 정의되지 않을까 두려워하지 않습니다.

---

Majd Taby와 Coobird의 답변이 정말 좋기 때문에 내 답변을 추가로 유지하려고 노력할 것입니다.

저는 대부분 절차 적 프로그래머였으며 OOP 프로그래밍에 맞서 싸우지 않았지만 실제로는 많은 관련성을 보지 못했습니다. 팀에서 일하고 더 중요하고 복잡한 프로젝트를 만들기 전까지는 말입니다.

OOP는 더 복잡한 애플리케이션을 위해 간결하고 유지 관리가 쉬운 코드를 작성해야 할 때 정말 빛납니다. 그리고 모든 상황에서 그런 것은 아니지만 절차가 제대로 작동하지 않는 경우가 있습니다.

훌륭한 OOP 구현의 대부분의 예는 모두 관련되었지만 약간 씩 다른 몇 가지 사항이있는 프로젝트를위한 것입니다. 많은 양식, 많은 사용자, 많은 제품 등이있는 사이트

모두 print (), update () 등과 같은 유사한 동작 이름을 가지고 있지만 객체로 캡슐화하고 클래스에서 메서드의 구현을 변경하여 런타임에 사이트 전체에서 코드를 매우 간단하고 깔끔하게 만들 수 있습니다. 또한 이것은 다른 동작이 있음에도 불구하고 전체 응용 프로그램에서 동일한 메서드 호출을 사용하여 다른 개체로 작업 할 수있는 핵심이었습니다 . 두 번째 개발자가 더 깊은 코드를 작업하는 동안 실제 구현 작업을 수행 할 수 있습니다.

그게 도움이되는지 모르겠지만 얼마 전에 당신의 상황에 있었던 사람으로 말하면 OOP를 좋아합니다.

---

프로그램에서 절차 적 프로그래밍 방식이 아닌 객체 지향 프로그래밍 방식을 사용하는 것은 언어 (PHP이든 아니든)에 의존하지 않고 해결하려는 문제의 유형에 따라 다릅니다.

(나는 PHP에 너무 익숙하지 않기 때문에 내 예제에서 의사 코드를 사용할 것입니다.)

예를 들어, 여러 기능을 순서대로 수행하는 프로그램이 있다면 절차는 괜찮을 것입니다. 예를 들어 간단한 문자열 조작 프로그램이라면 절차 적 접근으로 충분합니다.

perform_truncation(my_string, 10)
to_upper(my_string)
perform_magic(my_string, hat, rabbit)

그러나 많은 다른 항목 (예 : 파일 또는 객체의 다른 표현)을 다룰 경우 객체 지향 접근 방식이 더 좋습니다.

예를 들어, Cars 가 많고 s를 원하면 drive절차 상 다음과 같은 작업을 수행 할 수 있습니다.

drive_car(first_car)
drive_car(second_car)

OOP에서는 Car스스로 구동 할 수 있습니다.

RedCar myRedCar();
BlueCar myBlueCar();

myRedCar.drive();
myBlueCar.drive();

그리고 각 차가 다른 등급이기 때문에 그들의 행동은 다르게 정의 될 수 있습니다. 또한 둘 다 하위 클래스이거나 Car공통 기능을 가질 수 있습니다.

그것은 실제로 객체 지향보다 절차 적 접근 방식을 더 좋게 만드는 문제의 유형에 달려 있으며 그 반대의 경우도 마찬가지입니다.

절차 적 또는 객체 지향적 인 문제를 제외하고, 많은 기능을 가진 하나의 소스 파일을 갖는 것은 일종의 "코드 냄새"일 수 있습니다. 이것은 별도의 클래스에서 별도의 기능으로 더 잘 수행 될 수있는 많은 기능을 포함하는 클래스에 대해서도 말할 수 있습니다.

여기서 문제는 절차 적 또는 객체 지향 프로그래밍을 선택하기보다는 코드 구성에있을 수 있습니다. 함수를 별도의 소스 파일로 구성하는 것이 프로그램 작성에 대한 절차 적 접근 방식을 포기하는 것보다 여기서 필요한 것일 수 있습니다.

결국 잘 작성되고 유지 관리가 쉬운 절차 적 프로그래밍 접근 방식으로 작성된 많은 프로그램이 있습니다.

---

50 개의 함수가있는 큰 파일이 있다고 가정 해 봅시다. 왜 클래스에서이 파일을 호출해야합니까? function_name ()이 아닙니다. 내 모든 기능을 보유한 객체를 전환하고 만들어야합니까?

OOP로 이동하는 것은 위에서 설명한 방식으로 단순한 '스위치'로 간주되어서는 안됩니다.

OOP는 두뇌를 재배 선하는 프로그래밍에 대해 완전히 다른 사고 방식을 필요로합니다. 뇌의 재배 선은 하룻밤 사이에 일어나지 않기 때문에 많은 사람들이 필요한 재배 선 과정에 자신을 노출하지 않으려 고합니다. 불행히도 재배 선은 연구, 튜토리얼, 시행 착오와 같은 시간과 노력에 투자 할 것입니다.

It really involves taking a step back and learning about the concepts behind OOP but the payback will be well worth it speaking as someone who went through this process in the pre www days.

After you 'get it' and follow OOP best practices in your everyday you'll be telling others how your programming life has changed for the better.

Once you really understand OOP you will have answered your own question.

---

If you have 50 functions instead of 50 static methods into Utilities class, you "pollute" the global namespace.

Using a class with 50 static methods, method names are local to your class.

---

I can't say which one is better. but in my experience you can have better code management using OOP. you know which code is where, what functionality is defined in which file, etc. about the runtime overhead for OOP I read somewhere (and I think it is true) that if you write a bad code in classic functions, and the same bad code in OOP, the function version works better. so if your code is not written bad, there is no proof that OOP is keeping your application slow. also remember that these "slow" and "overhead" stuff are all measured in milliseconds. so if your application is not serving a lot of users (like more than 100 users in a minute), you might not feel any difference.

---

OOP allows you to create structured containers of code, called classes, which can be parents/children of one another. This can help with building an application as it is easier to maintain and can, if done properly reduce code redundancy. OOP does add a bit overhead but it isn't really noticeable and is outweighed by the unmaintainablity of procedural code. If your writing a big app, def go OO, especially if it is going to be worked on by many people.

For example, say you are designing a simple website. You could create a Page object. The page object is responsible for going to the database and getting various settings for the page, such as meta data, title tags, or even the number of certain "components" on the page and their type (such as a calendar control, a widget, etc).

Then, you can create another class, say Index, that extends Page. Index would be the index or home page. If you had a catalog of products, you could have Catalog class extend page. Since both your catalog section and your homepage need to get data from the database concerning the metadata of the page and the basic construction of the page, having 1 object that does it already for you helps. In both of these situations, page does all the work and gets the page data from the database, loads it into variables, which are then accessible in both your index class and your catalog class. You don't have to write code to go into the database and get it again in each page you write.

Now there are other ways to do this procedurally, such as with an includes. However, you will find yourself making less mistakes and errors. For example, you can define an abstract method in your Page class. This means that this method MUST be defined in any object that extends it. So say you created a setPageAttributes() function as abstract in your Page class. When you do this you create an empty function. When you create your index class, you HAVE TO create a setPageAttributes() function (with the intent on filling it in, such as accessing the variables defined in the Page class and using it to set the actual elements on the page, template, or view you are using) or you get a PHP error.

If you are working with other people to get your project written, abstract methods will tell the person, "Hey, you need to define these functions in any code you write". This forced the application to be consistent.

Finally, you cannot go to frameworks such as MVC formats if you do not do OOP. While it is not necessary to go to MVC and there is some debate, it does separate out all the components of the application and is necessary in environments where many people (designers, coders, marketing employees) work on the same code.

---

Use of the oop gives you following benefit:

1. Structuring
2. Reusability
3. Easy Maintenance
4. Encapsulation of the Data

Coming to the point of making big file with 50 function. You can do that but when it comes to the flow of the function and how the data data will be bind between every function will be a biggest problem.

Also for the future maintenance if you want to replace the biggest chunk of the flow, trust me you have to go to every function and play around it. Also you never know how your functions are used in other part of the code. So Object Oriented programming is always advisable.

For the detailed about the benifits you can read my post on OOP in PHP

---

The accepted answer seems to have neglected to state that it is possible to call functions based on a variable name such as in the example herew:

function drive($the_car){
    $the_car();
}

Admittedly there would need to be a function for each car in this instance but it's a lot more efficient than the suggested switch statement.

---

Additional variables can be supplied easily as such:

function operate($the_car,$action){
    $the_car($action);
}

function ferrari($action){
    switch($action){
        case 'drive':
            echo 'Driving';
            break;

        case 'stop':
            echo 'Stopped';
            break;

        default: return;
    }
}


operate('ferrari','drive');

There is a switch statement here but it's to supply additional functionality that was not in the original example so it's in no way a contradiction.

---

The OOPs concept is used in PHP, so as to secure the code. As all the queries are written in function file instead of code file so no one can easily hack our code. So it is better to use classes in PHP instead of directly writing the queries.

ReferenceURL : https://stackoverflow.com/questions/716412/why-use-php-oop-over-basic-functions-and-when