PHP程序员提到OOP的可扩展性，但是在OOP之前发生了什么？ [关闭]

Question

i have been told that OOP will replace procedural programming in PHP because of scalability.My question is what happened before OOP? was no PHP program scalable before OOP? is it possible to build a program in PHP using procedural code to build a program that can scale?

1. What happened before OOP ?
2. Is it possible to build a program in PHP using procedural code to build a program that can scale?
3. Why the obsession with OOP? and or frameworks(codeigniter, laravel ect )?
4. Why not just use mostly functions or some other method, is this not making the learning curve take years and years for new programmers?
5. And why do i hear a lot of negativity about relational databases? why is there a hype about non relational databases.

Whats your thoughts on this?

Answer 1

First off, note that this isn't really anything specific to PHP. Object-oriented programming was a revolution in programming generally.

But for your specific questions:

1. Before OOP, programmers had a harder job of keeping conceptually separate things separate in the code. If you want all your code relating to dogs in one place, it's much easier to do this with OOP. It can be done with procedural programming, if you're careful and have good code structure, but it's certainly messier and harder to deal with.
2. Yes, it's possible to write scalable procedural code. It does depend a little on what you mean by scalable, though. If you mean scaling to large amounts of data, then there's no real issue. If you mean scaling to ever larger programs and more and more functionality, then it's harder without OOP, but it can be done (and had to be done before OOP came in). This is really about extensibility and maintainability rather than scalability, though.
3. The obsession with OOP is because it much better matches the way we think. You write a Dog class, and it encapsulates all the doggy data and all the doggy functionality. Without OOP, you have to keep your data and your code separate; but that's artificial in some ways. When we think about a dog, we think about what data it holds (colour, size, breed) and what it can do (woof, run) all together. OOP enables this. Frameworks are a little different: they deal with things that lots of programs need to do, and would have to do for themselves if there were no framework. It is a way of saving programmers lots of time and effort and debugging, by doing lots of the work for them, and allowing them to concentrate on what's specific to their application.
4. There is a difference of opinion here as to whether it's best to teach OOP right from the beginning or whether to add it in later, after teaching procedural programming. The argument in favour of early objects is that it's more conceptual; but on the other hand it does mean teaching a whole lot more language features right from the start.
5. For anything, anywhere, in any context, someone is going to be negative about it! So I wouldn't get too worked up about this. Certainly relational databases have their limitations: they don't neatly capture objects, for instance, and you end up with frameworks whose entire purpose is to translate between the object world and the relational database world (ORMs, or Object-Relational Mappings). But don't be fooled by the negativity: relational databases are still standard fare in all types of programming, and they're not disappearing any time soon.