Programming education and OOP

Question

Just to clarify, I left school some years ago entering with no or very little programming experience. The programming classes was primary c++ and java. The focus was heavily OOP related with interfaces, abstract classes and so on. After working in the IT industry for some years, slowly the benefit of "real" OOP programming is becoming clearer to me and as I of course see the benefits I really feel that OOP is very overfocused in programming education.

I think there are thousand of things you would want to know related to programming before you need to know what a interface is. Maybe its just me being slow but I think the focus on the heavier parts of oop just messes things more up for students than it helps, it isn't that often you really need it and you shouldn't use it if you don't need it and it takes quite some time to understand that a abstract class isn't some kind of magic.

Is this a common perception of the school system, or am I completely off here?

Answer 1

I feel a bit handicapped by having started with procedural programming back in the day. I wish I had learned OO concepts well and truly earlier. If you come at it with no real experience, is it really that hard to grasp heavy OO? I'm just not sure.

Although it seems to me design patterns are best left until quite a bit later.

Answer 2

Object oriented programming is typically used in schools because it supposedly is easier to grasp for some students. Students usually understand the concept of "doing something" (methods) to something (objects). This is a little bit easier introduction to programming than using all sorts of functions and the like.

However, I do agree with you, as a CS undergraduate, OOP is heavily overtaught.

Answer 3

I think I would agree with you here. The real problem is that it can be hard to realize why things like encapsulation, abstract classes and interfaces are important unless you've programmed without them.

Seems to me like the best way to teach these things would be to provide assignments that force you to "code yourself into a corner" and THEN introduce these aspects of OOP in a way that would illustrate how you could have used OOP to avoid the problems you ran into.

Having started out doing some BASIC programming before college, then being introduced to OOP and C++, I could immediately see the usefulness of OOP and how I could have used those principles to simplify the BASIC procedural code I had written before. I think that someone who didn't have that non-OO background would have had a much more difficult time understanding why that stuff was important.

Answer 4

As a recent graduate in a similar situation, I think it all comes down to software architecture. What may qualify as "heavy OOP" in one design is completely necessary in another (e.g. a game with tons of unique but similar objects). I have recently tinkered with the Source engine, and let me say that if it wasn't heavily object-oriented, it would be extremely difficult (if not impossible) to understand how to code within it.

Answer 5

In my education of programming I went through a few different stages and think I turned out OK for the most part. Here is my progression through the various stages:

1) Procedural. Programs that are really very simple like can a triangle be formed with sides of given lengths or convert a measurement from metric to imperial or vice versa. The idea here is to get used to loops and conditionals and in the end get to making procedures to get a more modular code. Something as simple as Basic can be fine where there are integers, strings and floating point values to use in writing code.

2) Object-oriented. Now define different types and get them to do various bits of code. Inheritance, polymorphism and abstraction/encapsulation are the main points here. Interfaces are useful if you have a large programming project where one piece of code needs to talk to another, simple as that I think. Examples of types would include stacks and queues and using linked lists and arrays.

3) Functional. This gets really funky as now you have to work without variables and see what can be done. LISP and scheme would be programming languages used for this and it can be rather mind-bending to some extent for syntax as well as how you approach things.

Answer 6

I have no idea if CS education tends to be heavily focused on OOP, but my own experience is that relatively few people in the industry understand the benefits of OOP, or even how to practically apply it. This suggests to me that the quality of education in this area is lacking. Perhaps it's too heavily focused on the mechanics of programming rather than the philosophies of it.

Answer 7

School only gives you a taste of things and at times students will study for a passing grade than to master OOP or anything. Human mind does not think OO naturally, it thinks procedurally unless you train yourself to do it. OO can never be mastered even 50% just by some course you took. Knowing something exists is all school will do, improving and developing knowledge is upto the student.

Answer 8

My impression is that most colleges teach OOP very badly, and as a result you're not going to be prepared when you go out and get your first job. Rote memorization of the differences between interfaces and classes means precisely nothing -- knowing how, and when, to use one or the other matters a lot.

I don't know about you, but I got my education from some of the smaller universities in my area, and I was very unhappy with them. I can't tell you how many programming courses I took which were repititions of the same old ineffective teaching style: syntax-oriented learning. Programming courses are designed around teaching syntax, as if knowing how to declare an array and a class suddenly endows students the knowledge of how to use those structures effectively.

From my point of view, OOP is not overemphasized in schools, because -- in all likelihood -- your first programming job will require you to learn and use an OO language. The set of languages { C#, Java, Python, Ruby, Perl, C++, VB.NET, PHP } represent 99% of all software development you're likely to encounter in your first few years as a developer, and all of these languages are OO or support OO features. OO is in demand, and will continue to be in demand for years to come, so colleges will teach it at the exclusion of other programming paradigms (or at least until you get into your 600 level classes, then maybe you'll get a dose of Lisp and OCaml too).

With that being said, I've noticed from having worked in a few small software shops producing line-of-business applications that OOP is really underutilized. I actually find that most software is written using the front-ahead design methodology. Most business logic ends up in the UI, and the MVC pattern just isn't very prevalent. You don't really use the full range of OOP design patterns that you're forced to memorize in college. (At least that was my experience, but as always, your mileage may vary.)

So, we have two major reasons why OOP feels overempasized in college: 1) instructors teach it in a long, drawn out, and ineffective style. 2) OOP is actually used ineffectively by a large number of software shops. There's not much you can do about these problems, except complain to your instructors that you're not learning anything, and insist on writing correct, modularized code when you finally get your first job.

Answer 9

I have always struggled on when to use "real" OOP. I'd love to design something with Interfaces and the rest, but never seem to actually need it. I create classes but to me they are easy ways to refer to the same functions over and over instead of copying and pasting the same code where I need it each time. I know that the design is OOP in that I have a class and a method, instantiated, use it and so on. But it doesn't really "feel" OOPey to me like when I read about "real" programmers on their blogs and on stackoverflow. I just never seem to need the heavy stuff.

The closest thing I can think of to build is a program that uses plugins but I'm not sure that is an oop/ood or not.

I am mostly self-taught but have had some schooling. Maybe that is my problem, but when I was in school, the Java we learned was small programs that illustrated principles but not real meat. guess that's why it has 01 on the end of it.

Answer 10

There are some good answers here, and I agree with your frustration.

I was a professor of CS undergraduate, so I've got a number of feelings about this.

Most teachers have precious little practical experience, so they don't really know or care how useful what they teach is. Some are trying to groom students for grad school, so they fill their heads with obscure theory. I have sometimes asked professors about this, and they feel it is the real world's job to teach the practical skills. The problem is, students come in two modes, open mind and closed mind. In a classroom their minds are open. In a work setting they often feel it is their job to teach their coworkers, not to learn from them.

Teachers' main concern is to fill the time with material, any material, especially if it is the "next big thing". As a result they are prone to bandwagons and pseudo-religious schools of thought. They teach things as if they shouldn't be questioned. Then these attitudes rub off on students. OO is a good idea, but it has become a bandwagon because it provides lots of obscure material to teach, far beyond it's practical importance. Now that it is getting long in the tooth, teachers are looking for the Next Big Thing, and they have practically annointed Functional Programming as that thing.

I would much prefer that professors have enough practical experience with projects so they actually know and care about what is useful, and have a sense of perspective about it. Software should be treated as any other branch of engineering, where things are not "the way to do it", but have pros and cons that can be quantified.

Some personal hot-buttons are profiling, data structure, and information hiding. Profiling is taught as if it is "the way" to do performance tuning. Data structure is taught as if that's what programming is all about, so the more the merrier. Information hiding is taught as if everybody agrees that it is simply always the most important thing. All the resulting emphasis on abstraction results in software with so many layers that it has terrible performance, and its developers are loath to fix it.

I would much prefer at least one class that looked at project cases, and taught how to classify problems and come up with a range of possible solutions, with pros and cons.