Employer appeal; OOP use in mainstream; solutions that blossom with OOP

Question

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 found this post https://stackoverflow.com/a/1991453 to be specific to my predicament. Importantly:

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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 offers O(1) size. C strings only offer O(n) size.

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.

Answer 5

Is there any projects or problems I can tackle solo?

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.

Answer 6

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.

Answer 7

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.