Why Is Object-Oriented Programming Useful? With a Role-Playing Game Example

http://inventwithpython.com/blog/2014/12/02/why-is-object-oriented-programming-useful-with-an-role-playing-game-example/

by AlSweigart • 12 years ago

75 85 12 years ago

inventwithpython.com

lmm3• 12 years ago

I feel like a lot of the problems OOP solves are working around inadequate type systems. If you can make a distinction between Int @@ CharacterHP and Int @@ WeaponDamage such that you simply can't subtract one from the other without going via the appropriate function, then the argument for having private member variables and object methods to mutate them (which is the controversial part of OOP, I think everyone agrees with having data structures and some form of polymorphism) goes away, doesn't it?

humanrebar• 12 years ago

Right, but you should also include notions of immutability and ownership in your explanation. OOP is partly about managing complexity. If the mutation and sharing in your data is managed by the type system, private data is much less important.

That being said, OOP is also about managing interfaces between the different parts of your code. Adding a little more type info to your variables doesn't help you if you need to drastically change how a variable is accessed and mutated (memoized, retrieved from a service, persistence layer, etc.) while avoiding a running a giant find/replace across your entire project.

lmm3• 12 years ago

Adding a little more type info to your variables doesn't help you if you need to drastically change how a variable is accessed and mutated (memoized, retrieved from a service, persistence layer, etc.) while avoiding a running a giant find/replace across your entire project.

I feel like if you have a generic "context"-like notion then you can have a lot of this pass directly through. E.g. I recently changed where a Scala report gets most of its data, making it use an (async) web service rather than a database call, and I only really had to change the "top and bottom" - all the intermediate code handles any kind of context as a generic "F[_]", sometimes requiring particular typeclasses (Applicative, Comonad) depending on what it does with it.

woah• 12 years ago

Since this is aimed at new developers, I would encourage anyone who falls into that category and is reading this to also look at alternate programming methodologies. The key component of OOP is the mixture of code and data into "objects". This can be very useful for physical simulations such as games, etc., since the real physical world is actually made of objects.

However, many feel that applying OOP to software that is not for physical simulation has led to a huge amount of wasted effort over the previous decades. The problem is with code reuse. The only real form of code reuse that OOP addresses is direct object inheritance. If you want to reuse a piece of code, the way to do it is to make an object that is a 'subclass' of an object that has the code that you want to use. The actual relationship of these objects is often not that simple, and people often create baroque inheritance trees to force their logic into the OOP pattern. Worse, is that OOP is built into many languages, which leaves you no choice.

An alternate pattern is functional programming, where a program is modeled as a series of data transformations, instead of a universe of interacting 'objects'. To write the code, one looks at what data will go into the software, and what data will need to come out. After all, if the right data is coming out of the program at the right times, it works.

Instead of breaking code into objects, you write functions that process the data correctly, and assemble them into larger structures, often resembling pipelines. The nice thing is that a lot of these functions are very reusable across projects and within a project. Avoiding the messy mixture of code and data allows you to identify the common patterns in your code, and refactor and reuse more easily.

EDIT: Here are a couple of libraries which have really facilitated functional programming for me in node.js

- http://ramda.github.io/ramdocs/docs/

- https://github.com/dominictarr/pull-stream

evanspa• 12 years ago

To build on what you're saying, one could argue that functional programming also is a way to model the world; that is, if you're model of the world is that of a series of snapshots of instants, as opposed to mutable stateful objects. Abelson from the SICP lectures argues this in this lecture:

http://ocw.mit.edu/courses/electrical-engineering-and-comput...

zmb_• 12 years ago

Like you say, the main benefit of OOP is that it matches the way we perceive reality. That can make it intuitive to design software. However, this often comes at the expense of performance since the hardware that executes your system bears no resemblance to the way we perceive reality.

Take your physical simulations, for example. You may have a game scene with hundreds or thousands of entities. It's natural to try to model these as objects. In every frame you will then call a method on each object that applies a translation to its position. Very intuitive and simple. But unfortunately extremely inefficient for a computer to execute. You will likely pay a number of cache misses while jumping to each of your objects. And once you get there, the rest of the cache line where your coordinates are is full irrelevant stuff and therefore wasted (the other fields of your object).

For performance, you would want to have all your entities' coordinates in continuous memory one after another, and then apply a function to translate them all at once. Pretty much the opposite design from where OOP naturally leads you.

the_af5• 12 years ago

It's debatable whether OOP "matches the way we perceive reality". Many have come to believe this, but is it true? I don't perceive all of reality as a strict hierarchy of things constructed out of templates, with "is a" and "has a" relationships between them.

I don't think the main problem with OOP is performance, either. The problem is that it's not always the right or the most natural design approach, regardless of any performance considerations.

tolmasky4• 12 years ago

I kind of stopped understanding this explanation of inheritance (when I switched to composition of course ;) ). When I look at the world I see a universe of composition, we get molecules by composing atoms, atoms from composing protons, neutrons, etc. little "modules" that come together. More practically, everyday objects seem to follow this too. A motorcycle and car aren't both "refined" from some "wheeled vehicle" that car companies buy, rather they share some similar components that car companies buy. Their similarities are thus either emergent (interface/protocol) or a direct result of their shared components. In unity for example, you don't inherit every hit testable thing from some class (like you would in cocoa), but rather attach a collider to things that can be hit tested. The collider actually worries about one concern, and you can therefor conveniently attach multiple colliders to one object for example (makes it easy to form complex hit regions). Similarly things that are visible have renderers attached. This matches my intuition of working with real objects, where is buy parts and put them together, not think to myself which "master" part my new thing derives from, purchase it, then rip it open and start modifying it as step 1.

ww5202• 12 years ago

OOP is not that slow in a typical application. Pure functional programming's emphasis on copying everything causing excessive garbage has an impact on performance, too.

OOP's problem with performance is that it doesn't play nice with modern CPU's L1/L2 cache since most typical OOP implementations don't allocate objects in contiguous memory. But only a very narrow set of problem niches such as high data volume high performance simulation require packing data tightly to take advantage of L1/L2 cache. The hundreds or thousands of entities using OOP in a game won't cause a sweat. The cache problem would have an impact when there are hundreds of thousands or millions of entities and you need to process them 60 times per second.

The L1/L2 cache performance hit can exist in functional program, too. The list and it cells in LISP are not allocated contiguously. Basically any non-array data structures would not play nice with cache.

That just means to use the right data structures for the right job. For high data volume and high performance processing, use array. Whether it's used in the context of OOP is irrelevant.

jameshart• 12 years ago

You're assuming that an object is always going to be modelled as a heap-allocated struct-like block of memory containing all of its state. There's no reason that has to be the case, though. You could create a system with an object-oriented programming model whose data storage was array-backed/table-oriented. You could probably even code something like that up in a fully GC'd OO language like C#. The way Java and C# manage string intern tables is an example of the kind of specialized data backing that's possible behind externally OO interfaces.

Chris_Newton2• 12 years ago

Thank you for raising this. All too often debates about OOP get hung up on the overuse of inheritance. That’s a fair point, to be sure, but IMHO there are two much more fundamental limitations that are inherent in the OOP way of doing things.

1. In OOP, one object is special.

Whether it’s the object that is receiving a message or the object that gets a special designation like `this` or `self`, something is always given a special emphasis in a purely OOP design.

However, many useful algorithms take multiple inputs where none needs to be singled out in that way. Where do such algorithms live?

Trivial example: A symmetric binary operator like +.

Grown-up example: You don’t really model funds transfers by sending a `debit` message to one instance of a `BankAccount` class and a `credit` message to another instance.

2. In OOP, one object is special.

This is a generalisation of the point that zmb_ made. Usually in programming we don’t work only with single, self-contained data points. Most interesting things happen when we manipulate structured data and consider relationships between data points.

In purely OOP designs, we often see classes representing single data points, and then further classes to represent containers of that type. However, if the implementation of each data point is locked up behind the interface to a particular class, and then we have to access the points in each container through the container’s own generic interface, we are constrained in the access patterns we can use. Emphasizing individual, self-contained data points is often the wrong level of granularity for promoting either code reuse or efficient designs.

Example 1: What if we want to implement a more efficient representation of a data set that supports a different access pattern, such as the kind of continuous memory case zmb_ mentioned?

Example 2: What if we want to enforce constraints on a whole set of data, or model relationships between structured data of different types?

In each case, it may be very difficult to reuse existing algorithms that are locked up in methods on existing single-data-point classes. We might want to store the underlying data in a different format, and converting between formats just to access functionality artificially tied to a specific variation is likely to be awkward and inefficient.

If we instead build our modules as a set of fundamental data types and a set of accompanying algorithms — which could be as simple as a library of C structs/enums and functions using them — then the artificial barrier doesn’t arise. We can still present a clean interface/implementation for each module as a whole, but we aren’t forcing the implementation details to be separated just because Everything Must Be A Class.

tunesmith• 12 years ago

This criticism against OO programming is more of a criticism against junior-level OO programming. A lot of beginning OO programmers go crazy with complicated object models that aren't necessary. Composition is often a better way to go than inheritance.

http://en.wikipedia.org/wiki/Composition_over_inheritance

hcarvalhoalves• 12 years ago

This can be very useful for physical simulations such as games, etc., since the real physical world is actually made of objects.

Actually, OOP breaks down for this case (simulation) too.

ww5202• 12 years ago

The only real form of code reuse that OOP addresses is direct object inheritance.

That is incorrect and it's misinformation about OOP. The most important mechanism for code reuse is a function or method, and it's the essential part of OOP. You put code into a function/method that can be used repeatedly. Function exists in most languages and is not the exclusive domain of functional programming.

rebootthesystem• 12 years ago

I've always had a different view about OO vs Functional.

OO is beneficial to the programmer.

Functional provides benefits in performance, footprint and memory utilization.

You can solve any problem with either approach. Microprocessors don't care. I've written genetic evolver code in machine language (don't ask) as well as C, C++, Python and objective C. The OO languages make it easy for the programmer, while the Functional approach requires more thought, planning and perhaps attention to detail.

I tend to prefer The functional approach, probably because I did tons of real work using this model before OO came into my world. However, I certainly appreciate how much easier some things can be in OO. What I object to is this idea that everything today has to be an object, this is wasteful and slow.

Of course, I am biased. When you learned programming starting with machine language, then Forth and then C before touching C++ your view of how to solve problems computationally is bound to be quite different than that of someone who started life with, say, Java.

Arnor• 12 years ago

The only real form of code reuse that OOP addresses is direct object inheritance.

Composition is far more useful and effective means of code reuse in OOP.

Dewie2• 12 years ago

Yet composition in the OOP sense seems like it can be easily achieved in any other paradigm - so OOP does not seem to address composition in any distinct way.

pjmlp2• 12 years ago

The only real form of code reuse that OOP addresses is direct object inheritance.

This is not true.

COM, Smaltalk, Eiffel, BETA, SELF, CLOS offer different OOP models than the average Java and C# programmers are aware of.

You can have code reuse via composition, delegation, sub-typing, genericity, mixins.

OOP is nothing more than modules in steroids for those of us that started with languages like Modula-2 and Turbo Pascal, doing Abstract Data Types[1][2] programming.

[1] http://cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT90.p...

[2] http://www.amazon.com/Data-Structures-Abstract-Types-Modula-...

lmm3• 12 years ago

"OOP" means different things to different people. I think we can all agree that beginners should be encouraged to look beyond the C++/Java/Python object models and consider alternatives to direct inheritance, which is the core point here.

mathattack• 12 years ago

Your reaction was very similar to mind. I thought, "What benefit here is not available via functional programming?"

syntaxgoonoo• 12 years ago

I think a lot of developer don't really understand OOP, and as a result they mess it up. In many ways functional programming is more straight forward, easier to get your head around it, but you can still mess it up just as much.

I feel your statement above is a little naive. You should read some Martin Fowler. Be less reactive and more informed. Find balance.

Software systems, regardless of methodology, need good experienced designers There is no silver bullet.

bunderbunder3• 12 years ago

I wouldn't just blame developers; I feel like the OOP languages most of us have been stuck with deserve some scorn as well.

The major functional languages all come from academic backgrounds, and it shows. They're very principled, and a lot of thought is put into designing languages that are clean and actively encourage you to write clean code.

The major object-oriented languages, by contrast, tend to come out of non-academic environments. Their design was often compromised by pragmatic concerns (C++, Java), or by their being hobby languages being designed by folks for whom Barbara Liskov maybe isn't a household name. I don't want to hate on these languages too much - C++ and Java and Python and Ruby make the world turn, after all, and I suspect that's partially because they let you get away with so much. But they are what they are.

joshcanhelp• 12 years ago

Best description of functional programming I've ever heard, thank you

Impossible• 12 years ago

Game developers have been big on data oriented design (http://www.asawicki.info/news_1422_data-oriented_design_-_li...) in recent years. It's funny, because data-oriented design examples tend to look like the original ("bad"?) array of values example in the blog post. Most of articles on DOD focus on performance, which seems of least concern to most software engineers, but I think it helps with understanding how your data is transformed and results in easier to understand code.

I don't see how OOP is any more applicable to games than it is to other software. In a typical business or social CRUD app you can represent things in the same way you could in an OOP game. "Hero" becomes "User", "Monster" becomes "Friend", "Inventory" becomes "Account", etc.

Otherwise I strongly agree with you. I think all software should be written in a more functional or data-oriented style. The biggest reason I'd write OOP code now is that many game designers and programmers, and most popular game engines and frameworks, prefer OOP.

jowiar• 12 years ago

The only real form of code reuse that OOP addresses is direct object inheritance.

Not really, or at least, not with a well designed system. Give me a system with small, composable objects. I can reuse code by creating a new object for one of the components of the system, or by writing an object that knows how to talk to a previously existing objects. Sandi Metz' POODR [1] should be required reading for anyone who is writing object oriented code.

Functional programming is also worth learning as well, and Martin Odersky's Coursera [2] shows how Scala can be used for code that is both object oriented and functional.

[1] http://www.poodr.com

[2] https://www.coursera.org/course/progfun

epper• 12 years ago

[...] The problem is with code reuse. The only real form of code reuse that OOP addresses is direct object inheritance. [...]

Inheritance is a form of code reuse in OOP. Composition is another one which is often preferred since it does not have the issues you mention here.

Note that just a couple of days ago this was posted on HN: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... It's the definition that basically the inventor of Object Oriented Programming gave of OOP itself. One of the nice things he says is that he left out inheritance on purpose because he "didn't like it" the way it was done and wanted to "understand it better".

Regardless, I think your advice of learning other programming paradigms is great.

Kiro2• 12 years ago

To write the code, one looks at what data will go into the software, and what data will need to come out.

What if your program has no output? The applications I write seldom has. Instead they save down stuff or send it away here and there during the lifespan of the program. When they're done they just exit without any output. FP seems to be focused on one input going through transformations ending up in one output.

(I'm not a good programmer and barely know how to do OOP, much less FP.)

dragonwriter5• 12 years ago

What if your program has no output? The applications I write seldom has. Instead they save down stuff or send it away here and there during the lifespan of the program.

What is saved and what is sent are outputs.

FP seems to be focused on one input going through transformations ending up in one output.

That's not entirely untrue, but that one can be a set of simpler values, a processes can be values, too.

4ydx• 12 years ago

Functional programming is nothing more than applying the rigour of math to programming.

Tehnix• 12 years ago

The author should really consider some proper way of displaying code, instead of a textbox.

Also, for some reason, on safari the code is in one line, while on chrome it's in multiple lines, like it should be.

DEinspanjer• 12 years ago

The highest priority rule is the in-line which specifies white-space: nowrap; which doesn't preserve multiple whitespace. Firefox and Safari does what he says. I'm not quite sure why Chrome is displaying it differently..

rezistik• 12 years ago

I was talking to a friend who started doing web development transitioning from game development. I came from a JavaScript background heavily based around Lodash and 'nearly' functional paradigm. I was discussing my interest in more purely functional languages like Haskell and Clojure. Kind of rattled of my distaste for OO programming and how it just doesn't make sense to me, it seems like a lot of fluff and boiler plate when our most common use case is moving data from a form to a data store.

He made a lot of good points that with game development OO makes a ton of sense. I kind of agree. OO works amazingly with game development but with application development I'm really finding the functional paradigm so much more logical.

vespakoen• 12 years ago

Functional programming in JS is possible, ramda / wu (others?) make it very easy to get started, of course it is not as great as with functional programming languages, but still, it allows you to do pretty cool stuff, it's like lodash but with the callback moved to the first argument, turning something like this:

var isMultilanguage = function(field) {

  return field.multilanguage === true;

};

var isNotMultilanguage = function(field) {

  return field.multilanguage !== true;

};

var getMultilanguageFields = function (fields) {

  return _.filter(fields, isMultilanguage);

};

var getNonMultilanguageFields = function (fields) {

  return _.filter(fields, isNotMultilanguage);

};

into this

var isMultilanguage = R.where({multilanguage: true});

var isNotMultilanguage = R.not(isMultilanguage);

var getMultilanguageFields = R.filter(isMultilanguage);

var getNonMultilanguageFields = R.filter(isNotMultilanguage);

https://github.com/ramda/ramda

https://github.com/fitzgen/wu.js

krebby• 12 years ago

You also have those in Underscore / Lo-Dash:

_.filter(fields, {multilanguage: true}) _.where(fields, {multilanguage: false})

jdd• 12 years ago

The current stable version of Lo-Dash supports _.curry. In 3.0 Lo-Dash will add support _.rearg, _.ary, & _.curryRight. Using a combo of them you can easily create auto-curried functions.

  var where = _.curry(_.rearg(_.where,1,0));
  var isMultilang = where({multilanguage: true});

jameskilton• 12 years ago

Unfortunately for the OP, when it comes to game development, it's widely understood that OOP only ends up painting the developer in a corner eventually. Yes using Objects, Inheritance, and Polymorphism works well for a long time, but the more objects and deeper the inheritance tree grows, the more inflexible the system becomes. You also run into problems with reality. When the code hot path calls across multiple object types and a invokes a bunch of polymorphism every frame, the code is going to be slow and there's no obvious bottleneck. The code is slow because the CPU is constantly waiting for its cpu and data cache to catch up.

Game development today is moving quickly towards components, composition over inheritance, and Data Driven Design techniques. Check out the myriad of posts on Entity/Component systems that have sprung up over the past 10 years. It can be harder to grasp at first but has huge wins over the traditional OOP model.

adnzzzzZ2• 12 years ago

This "huge win" depends heavily on what you're making. If you're making simple games where performance is not that much of a problem (like most indie games) then moving to entity/component systems makes no sense and tends to make everything more complex than it needs to be. A good middle ground in those cases is to just stick with normal OOP with shallow trees (no more than 2-3 levels) and favor simpler types of composition like mixins whenever needed.

rrradical• 12 years ago

As someone who has made indie games with both traditional OOP and component systems-- I vastly prefer component systems. I disagree that they make things more complex. I found that they made things much simpler. Although, it does require learning about and possibly developing a component system.

If you are talking about very very simple games, it would perhaps not be worth the effort, but at that level basically any architecture will work.

yoklov• 12 years ago

Even indie games can benefit a lot from components, and a basic component-entity system is very easy to implement. Make component and entity classes, give the entities a list of components, put the update method in the component, and put most of your code there.

This is fairly different from the most popular/performant ways of implementing ECS's (there are no "Systems"), but keeps a lot of the benefits (much more flexible than traditional class hierarchies, easier to develop and design content for without writing new code, etc), while avoiding a lot of the complexity which makes component systems overkill for smaller games.

You lose a bit of performance (compared to other methods of implementing component systems), but in higher level languages this will likely be faster than trying to imitate C++ patterns (I could say more about this, as I've seen some travesties, but I won't).

angersock• 12 years ago

I don't know...the Gold Source engine and Half-Life 1 were heavily OOP, and they did just fine, even with some mods placing dozens of fully AI enemies onscreen at once.

In some parts--like rendering--OOP is pretty terrible. Outside of that, though, it's not inherently bad.

munificent• 12 years ago

You're making a false equivalence here. Yes, the game industry is moving away from inheritance and for the reasons you note and others.

That doesn't at all mean the game industry is moving away from OOP. Classes and methods still abound and work perfectly fine. Even if you go whole-hog towards ECS, the stuff you're passing around is usually still an instance of some class and not a bare public struct.

Encapsulating data and providing higher-level methods to operate on it works really well. Polymorphism is also powerful and useful in many places. Even subclassing is a good fit for some things. But just realizing that you need to dial back on subclassing doesn't imply that the first one or two things on my list are broken.

cportela• 12 years ago

<unrelated> Al, could you made the fonts on your site bigger, make styling via css not on each element and introduce some nicer Google fonts? Also, if you could use `<code>` and `<pre>` tags that'd be a solution where you could ignore the rest of what I said.

Reason being that I save these articles for later to show people who I try to teach programming and my attempts to save this page were unsuccessful.

Kiro2• 12 years ago

So yeah, in games OOP makes perfect sense but I have a hard time applying it in other code. I mostly build applications that make some API calls, save the result to a database etc. What is an object in that context?

The same goes for the classical Car and Animal OOP examples. Yeah, that makes sense but how often do you have such entities in a real code base?

Puts• 12 years ago

The problem with object-oriented programing is that it makes objects the most important abstraction, which it's not. I'd say states are the most important abstraction of a program.

I think I've grown so much as a programmer since I started thinking more about states and less about objects.

mrev19• 12 years ago

Wow I haven't seen that character record sheet in 30 years. So mewhere I have a 10th level elf fighter with 18's for every trait (17 for charisma just to break it up.)

Translation for non-D&Ders - I was so nerdy I made my own characters for my own games I was DM for with completely invented characteristics rather than rolling dice for traits like the rules say

lsiebert• 12 years ago

The weird thing is, many if not all of the arguments apply to C with structures, unions, and function pointers... and I don't know that consider that properly object oriented.

bsder2• 12 years ago

The problem is that object oriented programming is a premature optimization that has outlived it's usefulness.

Object oriented programming enshrines mutation.

Mutation is a good optimization when memory is expensive and fast relative to computation. Memory is now cheap and slow relative to computation. You can execute 100's to 1000's of operations in the time it takes to chase a pointer that is not cached.

Gurkenmaster• 12 years ago

If OOP encourages mutation can you explain to me why the String class in java is immutable?

bsder2• 12 years ago

It's a holdover from when Java was supposed to be a language for small machines.

However, if you're being snide, let me retort "So why does everybody in Java immediately recommend that you use the StringBuilder class instead of String?"

Why Is Object-Oriented Programming Useful? With a Role-Playing Game Example

Related Stories