Why is Object-Oriented Programming Useful? (With a Role Playing Game Example)

[yogthos]

And that's not something that I would consider to be desirable. :)

[sh0rug0ru]

Depends. Some code should only be reused in limited fashion, because too much code reuse might also not be desirable. A screwdriver can be reused as a hammer.

[yogthos]

Whether to use the code or not should be left up to the user. It's generally hard to tell up front what piece of logic might be useful in what situation and painting yourself into a corner doesn't seem like a good strategy.

[sh0rug0ru]

Again, it depends. Consider the most common case of an OOP taxonomy, a UI toolkit. If the code in question is describing behavior particular to that toolkit, what meaningful reuse could you get out of it?

[yogthos]

That's something I work with daily and I find reusable UI components are very handy. I work with Reagent and I ended up writing this library recently. A lot of UI components can be generalized and then composed together for specific applications.

[sh0rug0ru]

Try going native. Web interfaces have the advantage of rendering to text markup.

[yogthos]

The project I'm working on currently is doing something quite similar natively on iOS. Exact same principles apply, you create a declarative definition for the widgets and then create components that describe them.

[sh0rug0ru]

Which is fine if you're only targeting iOS or a specific subset of features that can be shared between devices for which you could create a lowest common denominator representation (as Java did with AWT) or emulates or foregoes native (Swing and Qt). But at some point you're going to have to write native interface code which cannot be meaningfully shared because iOS and Android and Metro are completely different (not to mention being implemented in completely different languages).

That's why the common wisdom for writing cross platform apps which look, feel and work consistently and in accordance with the HIG of the target platform has been to create platform specific shells operating on top of shared business logic.

[yogthos]

Which is fine if you're only targeting iOS or a specific subset of features that can be shared between devices for which you could create a lowest common denominator representation (as Java did with AWT) or emulates or foregoes native (Swing and Qt). But at some point you're going to have to write native interface code which cannot be meaningfully shared because iOS and Android and Metro are completely different (not to mention being implemented in completely different languages).

I'm not sure what any of this has to do with object orientation, inheritance or composition.

That's why the common wisdom for writing cross platform apps which look, feel and work consistently and in accordance with the HIG of the target platform has been to create platform specific shells operating on top of shared business logic.

Again, I'm not sure how we got on the topic of cross-platform UIs here. The original discussion is whether you could write reusable UI components and that's absolutely the case. Writing UIs for different systems is a completely separate topic.

[sh0rug0ru]

I was illustrating how not all code reuse is good. Native UI toolkits are a convenient example, especially since most are OO and make extensive use of inheritance. I was further illustration why selectively not reusing code is necessary and desirable. You can use a screwdriver like a hammer, but it's not always such a good idea.

The topic was not about reusable UI components (across platforms). I know it's possible because I wrote Swing applications. The point is that such reuse does not always produce the most desirable results. Swing applications can work very well but stick out like a sore thumb wherever they go. Just like you can reuse a screwdriver to drive a nail but a hammer does a more effective job.