Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


aclysma

Member Since 12 May 2007
Offline Last Active Mar 08 2013 03:06 AM

#5012532 Once you go OO, you never go back?

Posted by aclysma on 19 December 2012 - 12:29 PM

After being a C++ programmer for a little while and dabbling with Java, I have to say that in my opinion object-oriented programming is relatively worthless to me. I honestly don't see why I should ever bother worrying about whether or not a particular set of functions can "see" each other, or whether or not I can make two functions with the same name. Why would I ever want more code obfuscation like that -- two functions with identical names that can do two completely different operations? Why on earth would I ever want such a thing?

But this is of course only my opinion. I'm not unique in the way I think, surely, but I'm also probably not at all a rare, dying species of programmer.


Most of the projects I've worked on professionally did NOT do much in the way of data hiding. 99% of the member variables in a class were public. It was annoying at times.. every time you reached in to set a value you had to be careful that you wouldn't cause side effects, but ultimately those projects shipped. Unrealscript is an example of an everything-is-public OO implementation.

Data hiding is a good idea. But can you ship without doing it? Yes, definitely. It raises the requirement of others not screwing up when working with your code though. In the case of unrealscript, they made the explicit choice to not hide data for performance reasons of calling a getter/setter (in C++ it's essentially no extra cost due to inlining, but in script.. there was definitely cost.) But that decision was not without other consequence in the form of maintenance hassle.


#5012462 Once you go OO, you never go back?

Posted by aclysma on 19 December 2012 - 09:23 AM

I have no statistics so I'll make unsubstantiated sweeping generalizations instead Posted Image

Most places outside of games DEFINITELY do OOP, whether or not they understand why they are using it and its advantages and disadvantages. Most game studios/engines I'm aware of also do OOP. I've seen a very small shift away from OOP in favor of thinking in terms of data transformations.

In my opinion OOP is very often a good choice. But unfortunately it seems like this is the way *everyone* learns how to program and don't understand the pros/cons of that style. "This is the way thou shalt make software."

You benefit from OOP by easy data hiding/encapsulation, and if we mean OOP as in common language features, ability to use polymorphic functions and type safety/inheritance. It's also a well-understood style by the person coming behind you.

A bad side of OOP is that few people succeed in only having a single concern per each object type and so what often happens is you get large classes that throw a bunch of unrelated functionality together with its data, and it makes it very difficult to extract a single aspect of the class out for reuse. You end up creating generalized objects that are more complex than necessary to solve a problem. OOP is also a trap for people to make code that attempts to model the real world (i.e. your objects are "chair" or "car" when maybe the better solution would be SitableComponent or DrivableComponent that's attached to something more general). It's difficult to have the discipline to break down a seemingly simple object into the various concerns it has, but failing to do so makes bad OOP designs.

One alternative might be a data transformations style, where you have lots of homogeneous data and you simply rip through it all using loose functions. Even with such a style, you can think in terms of OOP and limit how/when/where you access data in those lists. And yet you can keep data and logic separated. In other words, you can get the advantages of OOP without using the class keyword.

I think OOP is so prevalent because it's almost always a decent solution and it's very intuitive. So for big companies that just want to grow a workforce of moderately skilled people who can make standard business software without needing to have the depth of understanding to choose what style to use, OOP is a good choice.

I think the most important thing is realize that you can get the benefits of OOP without using the class keyword, while skirting the negative aspects of it by either being careful to keep your objects single-minded or thinking in a more raw form of data transformations in sequence. Consider many solutions/styles and *think* about the tradeoffs you make with your choice.


PARTNERS