• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
fir

how alive is oop?

26 posts in this topic

I probably be considered for setting up flame war but this is not my intention i would like just get the information or some 'information feeling'

because to be honest i got no idea - i am working in procedural and modular paradigms for years and to not do  any way of oop paradigms 

so i got no idea if something changed over the last couple of years,

10 years ago OOP was popular Is it so much popular today of more or less? Is possible for someone to estimate how much projects are made in OOP versus how many procent projects are made in no-oop paradigms ? tnx for the info

Edited by fir
0

Share this post


Link to post
Share on other sites

I dont know where Mona get this 83.743% number...

 

But, I think its very popular... I mean... OOP is a 'way of thinking'... so, you may implement its concepts even in languages like 'C' ( that is not OO oriented )...

 

Btw.. today OOP come with other flavors... like 'Aspects', IOC,  and another concepts that help OOP projects to achieve better results...

 

But I think its difficult to estimate how much projects are done with OOP vs projects are not done with OOP... we must start thinking in What kind of projects? Enterprise applications? games? embedded applications?

 

OOP has its uses.. but will does not implement a 'printer driver' with oop concepts... I think the enterprise applications ( ERPs, accounting applications, etc ) may use some advantages of OOP ( like code reuse, easy of maintain, easy of understand, etc etc )

2

Share this post


Link to post
Share on other sites

I dont know where Mona get this 83.743% number...

 

But, I think its very popular... I mean... OOP is a 'way of thinking'... so, you may implement its concepts even in languages like 'C' ( that is not OO oriented )...

 

Btw.. today OOP come with other flavors... like 'Aspects', IOC,  and another concepts that help OOP projects to achieve better results...

 

But I think its difficult to estimate how much projects are done with OOP vs projects are not done with OOP... we must start thinking in What kind of projects? Enterprise applications? games? embedded applications?

 

OOP has its uses.. but will does not implement a 'printer driver' with oop concepts... I think the enterprise applications ( ERPs, accounting applications, etc ) may use some advantages of OOP ( like code reuse, easy of maintain, easy of understand, etc etc )

 I know it is maybe hard to estimate but was curious if most projests people see (in their work etc) are OOP or maybe most are not OOP,

 

I am outside of this and just dont know, I remember a couple a years ago almost all i was working with (but maybe only about 5 projects i got experience with comes to my mind) was OOP - but it was a couple of years ago and today it seem to me people talk less about it - but maybe

I am more unavare of this becouse i am doing things only in procedural and modular c so jm just unconscious of this

 

allright so probably i may assume it is still in use like it was before (i know android has oop framework enforced and iphone too, so it maybe even goes a bit further)

Edited by fir
0

Share this post


Link to post
Share on other sites

Even if you look through GitHub projects that use non oop languages you will see that people are still writing their code in an oop way. 

 

So yes it is very much alive.  To be honest there all of these paradigms are becoming irrelevant as languages are adapting to support all paradigms.  For example C++11 and Scala allow you to use Procedural, Funtional, OPP or a combination of these.

2

Share this post


Link to post
Share on other sites

OOP is still popular, and I don't think this will change soon.

However, while 15 years or so back, OOP was the one and only paradigm, today other aspects get more attention. One of the popular examples used to explain the concept of objects was having classes for geometrical shapes, and having a virtual method "Draw" that draw each shape. Today, few people would mix the data this way with functionality. There is clearly a tendency to separate data from algorithms. Don't put everything in one class just because it is somehow related.

One outgrowth of OOP are these static class methods used for math, instead of having global functions. What is the means of writing Math.Sin(x), instead of sin(x)? This is ridiculous in my eyes. Luckily, we don't have this nonsense in C++.

0

Share this post


Link to post
Share on other sites

If you want to design some kind of a UI with buisness logic OOP is common I would say. If you have to adress realtime algorithms which are also cache-optimized OOP will not win. Here you need to think near to your HW and OOP is not the best choise.

 

Greetings,

Kim

0

Share this post


Link to post
Share on other sites

I probably be considered for setting up flame war but this is not my intention i would like just get the information or some 'information feeling'
because to be honest i got no idea - i am working in procedural and modular paradigms for years and to not do
any way of oop paradigms
so i got no idea if something changed over the last
couple of years,


Depends. Are we talking about the original OOP introduced around 30 years ago (or more) before C++ was even a twinkle in Stroustroup's eye? Are you talking about the horrific OOP taught in Java schools (derived from the specific, limited, and inflexible "OOP" support in C++) and most terrible tutorials/articles on the web? Are we talking about the form of OOP that all but disallows inheritance or type hierarchies? Are we talking about a specific language's implementation of its object model or about object models in general?

The complex answer is that yes, it has changed, because the OOP you learned about a few years ago and which is encoded in languages like Java or (to a lesser extent) C++ is flawed and more people understand that today than they did a decade ago. This has led (in my personal belief) to a lot of fads pushing for "less OOP" when really people just want "less _bad_ OOP" (but they lack the experience/education to tell bad and good OOP apart). This similar in a way to the rise and fall of dynamic languages due to all the misconceptions of static typing based on the limitations of a few specific popular static languages like C++ and Java. C++ has seen a lot of growth in non-OOP code because it was (thankfully) designed as a multi-paradigm language and it's quite easy to use functional and declarative programming style _in combination with_ objects when appropriate while pure (or mostly pure) functional languages are not at all taking over. Edited by SeanMiddleditch
1

Share this post


Link to post
Share on other sites

One outgrowth of OOP are these static class methods used for math, instead of having global functions. What is the means of writing Math.Sin(x), instead of sin(x)? This is ridiculous in my eyes. Luckily, we don't have this nonsense in C++.

 

It depends.

 

Some people will look at this and say "well an angle is an object, it stores data, you perform operations on it, sometimes you want it's value in degrees, sometimes in radians, it only makes sense to store values 0 to 360 so let's overload all operators to enforce that", so they go ahead and design an angle class that does all of this for them, and now every time they need to operate on angles they get all their desired behaviour automatically.  And sometimes that's exactly what they need and sometimes it's overkill, but if it's what they need then it is a valid way of doing things.

0

Share this post


Link to post
Share on other sites

 

One outgrowth of OOP are these static class methods used for math, instead of having global functions. What is the means of writing Math.Sin(x), instead of sin(x)? This is ridiculous in my eyes. Luckily, we don't have this nonsense in C++.

 

It depends.

 

Some people will look at this and say "well an angle is an object, it stores data, you perform operations on it, sometimes you want it's value in degrees, sometimes in radians, it only makes sense to store values 0 to 360 so let's overload all operators to enforce that", so they go ahead and design an angle class that does all of this for them, and now every time they need to operate on angles they get all their desired behaviour automatically.  And sometimes that's exactly what they need and sometimes it's overkill, but if it's what they need then it is a valid way of doing things.

 

 

That's why I used `log' and not `sin' as my example of this situation. You can make all these functions be members of the number type, but then you'll find functions that take two arguments, where it's not easy to identify what you are doing as primarily being an operation on one of the arguments. Do you want to write x.hypot(y) instead of hypot(x,y)? Or y.atan2(x) instead of atan2(y,x)?

0

Share this post


Link to post
Share on other sites
The 'OOP' moniker covers a lot.  When I first started using C++ I was told (and naively assumed) that what I was learning was OOP.  In truth as I learned more I have found that modern C++ isn't really an OOP language.  Maybe I'm just splitting hairs here, but here's why I feel that way.  It lacks two fundamental OOP operations, virtual constructors and multi-dispatch.  These seem like minor things at first, until you start getting deep into OOP.
 
Virtual constructors allow you to treat an object, as truly an object.  Without being able to copy an object (due to fear of slicing, or loss of data, or change of type) a vast number of algorithms can't be performed.  There are ways around this, though usually all quite involved.  
 
Multi-dispatch is required to truly make use of the hierarchical nature of OOP objects.  C++ does single dispatch fine, and that's what people think of when they think of OOP.  But this is such a small subsection of the set of functions that you would want to exhibit virtual behavior.  Where-as virtual constructors are something most C++ programmers are aware they are missing, and can see its use; I find that few even realize what multi-dispatch can do and why they actually might need it.
 
These are fundamental operations much like + or / are to arithmetic.  You can do arithmetic without say multiply, but it wouldn't be pretty.  Likewise OOP programs often have ugly hacks, or unwieldy factories/managers to get around these lack of virtual constructors.  And sadly few seem to even realize all the awesome things multi-dispatch can do, and so don't even know why they would miss it.
 
This is all a bit off topic, as you didn't ask about OOP in C++ specifically; but I found in my case and in many others that a programmers first impression of OOP is through C++, C#, or java (which are all quite similar).
 
I personally don't think C++ is an OOP language.  Templates + the stl have proven to be far more useful and powerful within the C++ paradigm (I'm not saying they are more useful in general, just with the way C++ approaches things templates are more powerful that classes IN C++).  So much so that most modern C++ is about containers + algorithms, not classes (Alexander Stepanov brought about a truly ingenious change to programming).  Its not that classes aren't used, but for the most part they are pretty structures; they store data, give it a unique and concrete type, and manage RAII.  Where-as the number of classes with virtual functions in any given project I can often count on one hand, almost every function and struct is littered with std::vector and std::fill, std::for_each and std::map. Edited by Ryan_001
0

Share this post


Link to post
Share on other sites

I open up a can of OOP-arse on a daily basis laugh.png

 

Everyone has hit on it pretty well, it's one of several styles and paradigms that are ultimately just a tool in your toolbox - and having a full toolbox is what matters. Getting bent out of shape if OOP is "alive or not" is about as useless to me as talking about POCO or POJO.

 

(Plain Old CLR Object...omg just call them objects)

0

Share this post


Link to post
Share on other sites

The 'OOP' moniker covers a lot.  When I first started using C++ I was told (and naively assumed) that what I was learning was OOP.  In truth as I learned more I have found that modern C++ isn't really an OOP language.  Maybe I'm just splitting hairs here, but here's why I feel that way.  It lacks two fundamental OOP operations, virtual constructors and multi-dispatch.  These seem like minor things at first, until you start getting deep into OOP.
 
Virtual constructors allow you to treat an object, as truly an object.  Without being able to copy an object (due to fear of slicing, or loss of data, or change of type) a vast number of algorithms can't be performed.  There are ways around this, though usually all quite involved.  
 
Multi-dispatch is required to truly make use of the hierarchical nature of OOP objects.  C++ does single dispatch fine, and that's what people think of when they think of OOP.  But this is such a small subsection of the set of functions that you would want to exhibit virtual behavior.  Where-as virtual constructors are something most C++ programmers are aware they are missing, and can see its use; I find that few even realize what multi-dispatch can do and why they actually might need it.
 
These are fundamental operations much like + or / are to arithmetic.  You can do arithmetic without say multiply, but it wouldn't be pretty.  Likewise OOP programs often have ugly hacks, or unwieldy factories/managers to get around these lack of virtual constructors.  And sadly few seem to even realize all the awesome things multi-dispatch can do, and so don't even know why they would miss it.
 
This is all a bit off topic, as you didn't ask about OOP in C++ specifically; but I found in my case and in many others that a programmers first impression of OOP is through C++, C#, or java (which are all quite similar).
 
I personally don't think C++ is an OOP language.  Templates + the stl have proven to be far more useful and powerful within the C++ paradigm (I'm not saying they are more useful in general, just with the way C++ approaches things templates are more powerful that classes IN C++).  So much so that most modern C++ is about containers + algorithms, not classes (Alexander Stepanov brought about a truly ingenious change to programming).  Its not that classes aren't used, but for the most part they are pretty structures; they store data, give it a unique and concrete type, and manage RAII.  Where-as the number of classes with virtual functions in any given project I can often count on one hand, almost every function and struct is littered with std::vector and std::fill, std::for_each and std::map.

 

very interesting (though i do not understand such things (as virtual constructors or multiple dispatch), but seem interesting anyways (as i said im using procedular+modular c (and im quite ok here, but dont matter))

0

Share this post


Link to post
Share on other sites
I hardly use object oriented programming at all unless I need it. For game programming, it works very well, because it simulates "game objects" very well.

You create one class for lights, and then you create light objects that automatically have the properties of lights.

Object oriented programming also simulates the actual world well too. There are classifications for everything. A classification for fruit and a classification for trees, for people, and for animals.

Since animals are so variant (even those of the same type and gender), you could create a classification for them using OOP and vary them slightly.

Object Oriented only means that the programming style is oriented towards a mindset that all things are objects, and have a classification that separates them from other objects.

But still, people always use a form of object oriented programming:

- A class of numbers containing integers, and floating point values?
- A class for logical operators?

Just guesses.
0

Share this post


Link to post
Share on other sites

There is also the Computer Science definition for OOP languages too which is that in a Pure OOP language all data types are actually first priciple objects.  By that definition both C++ and Java are not OOP languages.

 

 

However the OP and most of the replies here are focusing on the engineering aspect of OOP which is obviously still alive and kicking.

0

Share this post


Link to post
Share on other sites

I also use classes for everything ( even when used once ), exept for the main function ofcourse,
it makes things more managable, so you wont have globals shattered around.

Classes are not inherently object oriented. They are an organizational tool. The paradigm of an object-oriented approach does not require class and struct-style types. They make using that paradigm easier, but they are not a requirement.

There are many, many, many programming paradigms out there and you can be using many at once (see earlier in the thread). You can have classes and still be following an event-based paradigm, or be following an automata-based paradigm, or a flow-based paradigm.

Just because you are using classes and objects does not mean the code is following an object oriented thought process. Classes tend to guide toward that style, but that doesn't mean OOP dominates the processing paradigm.
2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0