I disagree. OOP is not a difficult concept and not hard to teach. For an example of what happens when "OOP must not be taught to beginners", see PHP.
For all its (many) flaws, PHP was (and is) an extraordinarily successful project relative to the vast majority of programming projects attempted. This is in fact a confirmation of the original post's thesis. The theory is that teaching OOP to beginners bogs them down worrying about the architecture of their code before they've had any experience solving problems at the scale where the architecture matters. It's easy for a beginning programmer to waste hours on pointless refactoring that doesn't actually improve their program in any meaningful way, simply in order to appeal to some professor, teacher, or other religious figure's concept of "good code". PHP, on the other hand, said "screw you religous types, we're just going to design a product people will use."
The reason that OOP should not be taught to beginners is not because it's a difficult concept. The reason OOP should not be taught to beginners is that it is an advanced concept. There are many other important fundamentals that can come first.
That's not my premise. I just point to PHP (and its community) as it has some examples of it.
>The reason OOP should not be taught to beginners is that it is an advanced concept.
I've never quite got this. Spend any time writing code that's not using classes and you end up reinventing OOP anyway.
I've never quite got this. Spend any time writing code that's not using classes and you end up reinventing OOP anyway.
I think that letting beginners rediscover this for themselves and then exposing language constructs that make this easier probably allows a smoother path to enlightenment.
It's often not obvious to beginners why copy-pasting code a bunch of times is bad compared to using loops and functions for example. It certainly wasn't for me, until I tried to build a program that was not highly trivial.
class Hello {
public static void main(String args[]) {
System.out.println("Hello, world!");
}
}
(print "Hello, world!")
Here's a sample programming problem a beginner might encounter: CIDR data is available as a "127.0.0.1/8" style string and you need to access the IP and Netmask separately. In python, the simplest, most straightforward path to a solution that still results in encapsulated, re-usable code is to write a standalone function that accepts a string and returns a tuple. You could also create a CIDR class with a "to_tuple" method, or that stores the values in 'ip' and 'netmask' attributes, but this is simply extra scaffolding and without knowing more about the larger context of the program it's impossible to know whether such a design will be beneficial.
The problem with beginners is that they'll see the straightforward solution, but because they're not just trying to solve a problem but also demonstrate "Object Oriented Programming" skills to their teacher, they're going to worry about doing a whole bunch of extra work that may not be appropriate. I believe this is wasted energy that could be spent gaining real experience solving problems and learning about how computers and software work.
I find that it only really makes sense from a code structure point of view once you have got to programs that are significantly bigger than the average beginner is likely to be writing. Even as somebody who understands OO I don't tend to use it for programs that are less than at least a few thousand LOC because I find that it just gets in the way.
"Spend any time" implies substantially more experience than what most beginners possess, hence the term "advanced." "Intermediate" might be a better term in an absolute sense. OO design is something to learn after you understand the basic tools and techniques.
Also, a lot can be accomplished without OOP (for most values of OOP) and even if you're writing de facto OO code, it's not always clear whether using explicit OO language features is a net win or not.
Only if you start with C. I find that if provided with reasonable alternatives (like function composition) or consistently restricted problem domains (vector manipulations) you very well might never create anything resembling objects.
It's probably easier to talk about it if you've done a little imperative programming and can grasp OOP as a solution to actual problems, rather than just some abstract nonsense.
Yes, I think this is a real distraction. This Cat/Dog/Animal trope leads to the view that you should use classes to model your domain objects. In some cases, you should. But this can cause as many problems as it solves, and should not (IMO) be the default approach.
In getting away from this view, I've found it helpful to think of most programming as designing DSL's. To that end, you can use OO to build the infrastructure necessary to support this. But I worked in OO languages for many years before grokking that.
$x = new Object;
$x->bar($foo);
$x = object_create();
object_bar($x, $foo):