I'm currently in the process of what I hope to be a career change into the programming field. Despite my wide range of knowledge in the field and additional exposure to concepts in college (which in the end left a lot to be desired), I feel I might be missing out on what really matters when appealing to employers.

I've seen a lot of terrible C++ code and it's not just from people who don't understand the concepts. I've seen a lot of coders who know exactly what an object is and can explain polymorphism and all those technical OOP terms perfectly. But if they don't know when to use it, they'll never be able to take full advantage of it. I know because I was like this myself. I had read a book on OOP in high school which explained all the concepts, but I went years before I actually used them because I didn't see when they'd actually benefit my code.

I am comfortable with OOP concepts but a little rusty with supporting languages like Java, C# (my favorite for OO), and even C++. The reason I can't claim to be at least proficient in this area is because I'm not really sold on OO design; everytime I set out to solve a problem that can be done in OOP, I find myself forcing its use and end up making a procedural solution in C which I believe to be a much more elegant program.

I guess this involves three questions: Can I still (honestly) sell myself as being valuable to an employer given my skill-set strengths and weaknesses as explained above? Is there any projects or problems I can tackle solo (for practice) that is just smarter to do with OOP? And given an object strong project, what language should I concentrate on?

This question came from our site for professional and enthusiast programmers.

2

OOP isnt a silver bullet. procedural solutions in C are likely to be more elegant.
–
RaynosJan 7 '12 at 16:46

"but a little rusty with supporting languages like..." What kind of career change are you making? If you want to be a programmer, what languages do you know? Why not simply look for jobs focused on those languages?
–
S.LottJan 7 '12 at 22:08

Ha! Well, I've been a Sports Performance Coach for over a decade, but programming is what I went to school for (emphasis on software engineering). I know Visual Basic, C, Ruby, and assembly on a couple of architectures, but am no stranger to C# or C++. I guess I use "rusty" to mean "not so light on my feet". The past 6 months I have had trouble properly portraying my skill-set to employers. I may not have an employable skill-set at all!
–
cantide5gaJan 7 '12 at 22:21

I find it odd that you feel you know Ruby but don't see the benefit of OOP. Ruby is like Smalltalk without the image. I recommend reading (or re-reading) The Pragmatic Programmer, as well as Design Patterns. Design Patterns in particular demonstrates the use of OO principles to create maintainable, re-usable code.
–
Jason LewisJan 8 '12 at 19:06

@Jason I think folks are thinking that I don't know OOP. I want to know it better and want to know how it can better my code. I've started and finished plenty of things in Ruby, C#, and C++ but feel it was forced into an OO nature. (Eh, i'm biased when it comes to Ruby because I hardly feel like I'm doing the OO thing; it just flows well). A solid answer is that Design Patterns reference. That is the type of literature I need to be reading.
–
cantide5gaJan 8 '12 at 20:12

7 Answers
7

I think the most common misconception about OOP is that it's supposed to make writing software much easier. That's where some of the criticism comes from, because when writing software, OOP often means more and sometimes even less natural code. That's what makes it hard to see the benefits of OOP, as everyone who starts programming just writes new programs and never has to maintain existing ones.

However, the real benefit of OOP only shows when you have to maintain software over the years, while constantly changing parts of the program in ways nobody expected when they were first written.

You should see OOP as a way to make sure that local changes to the software stay local and don't affect the rest of the program. In this sense classes are sort of explicit placeholders for future changes. In a procedural program it is often hard to see where you have to change the code to add a completely new feature, without affecting anything else.

Surely you can write procedural programs that are also extensible, but you have to think about it and design it properly. OOP provides you with a general idea of how programs can be structured to keep them maintainable, which means that don't have to think about design that hard! The same goes for other programming paradigms, OOP isn't necessarily the just the most common right now.

So in conclusion I think the only way to really understand OOP is to change and add features to existing software. This is the most common task for programmers anyways, and it's supposed to be easy! Not having a good design makes it harder than it has to be.

That sort of makes it hard to answer your question, as any project can benefit from OOP if it's complex enough and needs to be maintained and expanded. I think projects that can have any number of unforeseen features, such games or bots would be good examples. You can also work on a open source program, that is in general the best way to practice advanced programming.

Thanks for your thoughts. Assuming you work in the field, was learning your appreciation of OOP an on-the-job experience? I'm hardly new to this stuff, just find it hard to relate to team practices when all I've ever done is tackle it solo from the ground up.
–
cantide5gaJan 7 '12 at 17:58

1

I had written a website (~5000 LOC of PHP) without just basic ideas about design. It got fairly popular and I kept adding features, but each new feature took longer to implement and required more changes. It got so frustrating that I gave up and rewrote it using a OO framework. I still made a lot of mistakes, but the framework guided me in the right direction and showed me how a good design helps with changes. In my current job I maintain a large webshop, written without any OOP. New features that should be easy often require me to change code in many places and that costs a lot of time.
–
Jochen RitzelJan 7 '12 at 18:42

Hard to replicate for practicing OOP, but good example of purpose.
–
cantide5gaJan 7 '12 at 18:46

Maybe for practice the combat in a typical RPG would be a good example. You start with a Player, Monster and normal attacks. Then you randomly add features like ranged attacks, elemental damage, armor, resists, critical strikes and so on. The goal is not to think of all the features from the start and not to simply implement the new feature, but to change the existing design in a way that gives the new feature and rather obvious way to implement it, either by inheritance or aggregation. At least that is how I learned: from my mistakes, thinking "if I had only wrote this differently" ;-)
–
Jochen RitzelJan 7 '12 at 20:01

First, not every application should be shoe-horned into the OO paradigm. Procedural programming is very much alive and a viable alternative to OO for some cases (javascript and php for instance). If you can indeed cleaner, more expressive, and more effective code in a procedural style than a coworker could using objects, then you will certainly have value to an employer. All that being said, any employer hung up on buzz-words (whose money still spends) or who employs an application designer whose design you are expected to implement, may be less than satisfied if you are (uncertain? unconvinced? I know I was unconvinced for a year or two) about OO concepts. I would suggest you try a book on design patterns (Head First Design Patterns is great) to perhaps take your OO understanding to the next level. Hope this helps.

It does, thank you. It is a far-out question, but the consensus is what mattered to me: you folks know what is important. My strong experience with machine code (for example) is hardly "important" when appealing to an employer I have found. Time to get with the times I guess.
–
cantide5gaJan 7 '12 at 17:09

Yes, many. Take a simple project around a subject you know something about, say student registration in a college. Focus on a class such as Person. Now the Person may be a professor, an admin, a student, etc. So what is required to maintain registration for a set of courses? Thinking along these lines can help you set a scope for your project. Make sure you cover about 5 classes at the most so that you can focus on the techniques rather than the business itself and begin applying what you know to build an application that solves the problem. Stay away from fancy GUI, or sophisticated database methods since it is not the objective. The objective is to practice OO concepts regardless of whether the data gets saved in a file, XML file, or a database.

Another way, and it may be better, is to pick a book that uses an example in a language you like, say Java or C#. Such books would have "OOP" or "Beginning OO" in their title. Make sure you browse the book and feel like you want to go along with it before you buy it.

When you have covered the basics, you may want to move to more theoretical books about OO Analysis and OO Design including design patterns.

Thanks for the suggestions. I had thought of designing a GUI as embracing all there is in OOP, yet you suggest otherwise. Can you elaborate on your take?
–
cantide5gaJan 7 '12 at 23:44

Thanks for your comment, I suggest you focus on the fundamental concepts like properties,methods, inheritance, class design, interfaces, etc. first. These concepts are very important to be able to read code and learn. GUI technologies are many and take time to master (e.g. HTML/CSS). So as not to distract yourself, use the simplest GUI if you want but focus on the core of OOP. When you are comfortable with the fundamental concepts, choose the GUI interface that best suits your need and learn it more.
–
Emmad KareemJan 8 '12 at 9:24

To hit this from a different attack angle, Is there anything preventing you from using your domain expertise in your primary profession to write software? Can't you imagine an application that would make it easier to do your current job? I don't know what a sports performance coach does, but I can imagine that keeping records of the progression of the people you are coaching and charting that progress could come in handy for you and for the people you mentor.

If you build an app, using OO techniques or otherwise, you'll get some experience applying those techniques. If you partner with another friend with software development skills, you'll start to understand the software engineering problems (branching and merging code, for example, and real world team collaboration problems). If you ship the app (by offering it for free or for a fee to your peers in your current work), you'll get the rest of the experience needed to understand how to support and maintain an application. As you maintain the application, you'll hopefully come to understand the weaknesses of your initial design as you start accommodating feature requests and bug fixes.

Of course, this presumes that you don't have an urgent need to replace your current job, but when you're done, you'll either have the makings for a small business or enough experience to convince someone else to employ you.

A realistic tip that answers all of my questions. I have done something like this before, but I don't know of anyone that I could collaborate with. Just a bunch of meat head athletes, which I admit I am one of! I'm considering throwing my portfolio of code on BitBucket/GetHub and attempt to transform some things using OOP. Maybe contributions to GnomeLove might be a good idea. Might there be better places to contribute and/or find collaborators?
–
cantide5gaJan 8 '12 at 3:45

The best place to find collaborators is among friends, in my experience, but you might just kick off an initial release on your own. FWIW, I know that at least one of my managers and some of my peers in the software industry were among those "meathead athletes", so you may be surprised by potential of at least some of the folks. If you don't have friends in the software world, meet some through, for example, Meetup.com, which has many programming-focused meetups.
–
JasonTrueJan 9 '12 at 1:16

Like any other concept, OOP can be misused. I've seen many remark it's intended to map the real world concepts, and IMHO this path leads to eerie mind states from which subjects can not be expected to escape, producing nothing but crap.

Chances are your taste is right, and the non-object-oriented solution is better. I think all you lack is confidence.

Is it that obvious? I have a couple interviews coming up with a couple already behind me. I know I am valuable because I at least have a solid foundation that can learn anything that is needed. I just have a difficult time defining my worth compared to others just jumping into the field. Thanks for reminding me to man up.
–
cantide5gaJan 8 '12 at 20:31

There's no such thing as an elegant program in C, unless you count exceedingly trivial examples. The advantages of OO become inherently apparent as soon as you try to do even something basic, like strings. If you can't see why std::string is so much better than C strings in every possible way, then you need to take a much closer look. I'll give you a head start by demonstrating some of the massive benefits:

The Standard string class handles all it's own memory- specifically, you are guaranteed to never, ever leak a std::string. This is way ahead of a C string.

The Standard string class does not require NULL termination. This solves many off-by-one errors that exist in C string code.

The Standard string class cannot have it's memory freed by another user. It cannot have the memory be reallocated by another user. The ownership is explicit and enforced by the compiler. If you pass a char* to a function, they could attempt to free it when you already do that, or such things.

The Standard string class is smarter than you. Specifically, it can do things like small-string optimization without having to change your user code. If you wanted to implement SSO, you would have to refactor every single bit of code that uses strings. When std::string implements SSO, you don't even notice.

The Standard string class is generic. The function for sorting a vector of integers is just the same as the one for sorting a vector of strings, and it's faster than C's qsort too.

The Standard string class grows itself when it needs to. No more MAGIC_BUFFER_SIZE codes which overflow and are vulnerable, and you can guarantee that your library implementer spent an awful long time, much longer than you could ever justify spending, profiling and determining the optimum way in which to grow.

When you compile in Debug mode, the Standard string class will error-check your iterators and indexes, and when you request it, indexes in normal code too. Will a char[] do this for you? I doubt it.

So std::string is faster, safer, and more maintainable than C-strings. Other classes offer very similar reasons to be vastly superior in every possible fashion. What more do you want from object-orientation other than superior speed, correctness, and ease of maintenance?

Therefore, pretty much by definition, any C++ program that is equivalent to your C program but uses OO to handle strings is inherently and vastly superior to your C program.

The problem that you exhibt is most easily picked up on here:

I believe to be a much more elegant program.

You believe? Awesome. Why don't you actually go back and check? Because I think you'll find that actually, said programs are buggy and slow, and would be greatly improved by a judicious application of solid object orientation. Your subjective feelings arise for reasons that have nothing to do with the actual quality of the program.

You need to recognize that the objective qualities of speed, maintenance, and correctness of a program has absolutely nothing to do with your subjective opinion of whether or not it's elegant.

And you know what? Not every problem is best approached by OO. There's a reason that languages like C# have lambdas and generics, and it's because inheritance isn't a Swiss army knife. It's just one tool, and there are others which serve certain purposes better. It is, however, a remarkably effective tool for many situations, best used for structuring programs and modules.

Maybe I'm misinterpreting your tone, but I've hardly ever taken a stance against OOP. My efforts here are for suggestions for situations/projects where I can really get the most out of OO concepts. Goodness man do I know the advantages of it along with the standard library; your string rant was really not needed. I just want to embrace it because that is how a lot of things are done anymore. I hardly have the real-world experience to sway you with my 'beliefs' and 'opinions'... that is why I'm here!
–
cantide5gaJan 8 '12 at 20:03

@cantide5ga: It is not supposed to be a rant, although if it sounds like that, it is my fault, not yours. The only point I'm trying to make is that even in basic, fundamental things like strings, OOP is objectively vastly superior.
–
DeadMGJan 8 '12 at 21:58

Your reply points out a flaw when it comes to my experience. I have almost never been involved in a project involving someone else's code (i.e. libraries other than standards). I make my own versions because of my need to understand it through and through. I mention in another comment about throwing some stuff on BitBucket/GetHub or getting involved in Gnome Love in order to circumvent this and see how OOP makes collaboration easier. What are your thoughts?
–
cantide5gaJan 8 '12 at 22:21

OOP is inherently silly. Why would you ever write "object-oriented" code? Do people also build concrete-oriented houses? Wheel-oriented cars?

OOP takes a useful tool, and elevates it to a religion. An object can be very useful as a tool in helping you define your program. In the same way that a wheel is quite a useful component when building a car. It's just not something everything does, or should, revolve around as the term "OOP" implies.

Objects are useful because they enable us to define abstract datatypes. We can define a class which behaves like the concept we wish to model, and that simplifies all the code that manipulates these concepts. A string class is useful because it behaves like you'd expect a text string to behave. It defines a number of operations which you expect to be present when dealing with strings, and it prevents other, nonsensical operations which would be possible if you were working on the raw bytes it uses internally. It allows me to think about strings, instead of thinking about arrays and integers, which are used internally to define the string.

The same should be true for the objects you define yourself. They should provide abstractions and guarantees and invariants that allow you to forget about all the implementation details. The point in a class is that it should guarantee that it can never be "broken" or brought into an inconsistent state. That you can rely on it to behave like the concept it represents.

If you have some such objects, then you can use them as building blocks for your application.

But that doesn't mean your code needs to be "object-oriented". It doesn't mean that the objects should be your program, or that everything must be associated with an object.

OOP is nothing special. It's one programming paradigm out of many. There's object-oriented programming, there's generic programming, there's functional programming. There are "niche" ones such as logic programming, and "old-fashioned" ones like procedural programming. The point is that, generally speaking, OOP is not "best". It has had a powerful marketing machine behind it, but that doesn't make it superior.

The best you can do is try to learn as much as possible for as many different paradigms as possible. Then use what makes sense in the language you're currently working in. Some languages make OOP easier, and everything else harder, which generally means that OOP will be a more attractive choice. Others favor FP, and some allow just about any paradigm.

As for employers, the good ones will hire people who are good programmers.
The bad ones will chase buzzwords. (You know OOP? XML? SOAP? TDD? Great, you're hired!)

So don't worry too much about making yourself attractive to employers. Focus on making yourself a better programmer. This involves keeping an open mind and challenging yourself. If OOP didn't "click" for you, then don't take this as an excuse to go back to what you're familiar with. Throw yourself at new challenges. Perhaps take a look at OOP from another angle, in a different language. Perhaps take a look at functional programming. Try to learn new things, and even if they seem inferior to what you already know, give them a fair chance, and accept that your initial impression might be wrong -- but in the end, use your own judgment. There's no silver bullet, and your criticisms might be perfectly valid. Just don't use them as an excuse to stop learning.

"OOP takes a useful tool, and elevates it to a religion." I was bracing myself for this type of stance, even though it is clear I am asking to be converted. "Focus on making yourself a better programmer." That is what this is all about. Having a job doing what I love sounds great!
–
cantide5gaJan 8 '12 at 20:15

@jalf - I upvoted you because you make some good points, but if you want to avoid downvotes you might want to avoid phrases like "OOP is inherently silly". That's neither accurate nor constructive.
–
mikeraFeb 6 '12 at 9:07

@mikera: but it is accurate. Read what I wrote. And think for a second about what OOP stands for. "Object-oriented" programming? Are the objects really what matters? It's an absurd thought. If this hurts people's feelings, that's their problem. I stand by what I said. Objects/classes are useful tools to use in your programming, but they are not, should not be, and cannot be something you orient your code around. They do not deserve to be elevated up to some sacret status above all the other aspects of your code.
–
jalfFeb 6 '12 at 9:35

1

And if you think I "make some good points", but that my first paragraph is not accurate, then you haven't understood what I said, and you should remove your upvote again, because "OOP is silly" is really the executive summary of what you call my "good points".
–
jalfFeb 6 '12 at 9:35