To oop or not to oop?

[cassius]

I have decided I do not like oop . I did some checks on google and it seems that 57% of programmers do not like it either.My aim is to write as little code as possible and it seems to me that oop is quite verbose and can become over complicated.

One source claimed that oop is almost a religion to some of its devotees. Well I don't know about that, but would welcome some opinions.

[MikeClarke]

Starwars is a religion to some of its devotees that doesn't make it so.

Yes OOP can become extremely complex beyond initial planning and it's not hard for that to occur when you get sidetracked.

 

When I refer to oop i refer to perl & php as that is where my experience generates (Started using perl at 10, switched to php at 15 and been using it for 10years).

 

I think OOP is very powerful, but its easy to get distracted and go into too much depth craving perfection, obviously you can streamline code after it's written and clean up the formatting - despite what many people say I have never seen a 24hr coding session end up with neat code lol

 

If your referring to LE I would go with C++ and just use LUA for initial creation of features, then once your 100% happy with them (or near) covert them to C++

[beo6]

I come from PHP coding starting when PHP didn't fully supported OOP.

When OOP came more and more it looked nice but it was hard for me to start thinking in OO so i had trouble designing my code in it.

 

So i was just like that. I thought OO coding is just overcomplicating everything.

 

But then i started to force me more and more into using a Object Oriented Framework. It took quite a long time to overcome my fear about OO development and i still think for short examples and scripts it can still be useful to code procedural.

 

OOP can really help you later on when you need to extend your application, fix issues or redo parts of it.

It also helps you to better understand later what you have done in your code if you need to do maintanance.

 

 

I don't say i mastered it fully and know all the design-patterns that can be used, but you should really look if it is not really better to use OOP instead of procedural programming.

[MikeClarke]

I don't say i mastered it fully and know all the design-patterns that can be used, but you should really look if it is not really better to use OOP instead of procedural programming.

 

I wonder if anyone has actually "mastered it". One of the old adages is someone can always do it better. I think even Bjarne Stroustrup will have came across people recreating his works in a more streamline or efficient manner. It took 1 person to invent the wheel, but millions since have improved upon it.

[Naughty Alien]

All I can say is, oop helps a lot when code structure become large. It is very easy to debug or maintain large code base and patch it, if it is oop based. I came to conclusion, that procedural programming is incredibly efficient in cnc and robotics programming. Bottom line is, programs could be written in either oop or procedural way. Only difference is that code design will be radically different, so, whatever suits best, given project, ill stick to that. Personal preference over code style, shouldnt overtake best way to do things on given project. Also, I figured out that in certain situations, mixing both styles is incredibly good.

[Rastar]

I don't think that OOP is overcomplicating things, things really *are* complicated. OOP forces you to adhere to a certain structure, but that structure really is badly needed when code bases grow larger. And there really are a lot of design patterns and best practices to help you with structuring your code. I find thinking in terms of objects quite natural and helpful, but that might be just a matter of taste.

 

That being said, I have more recently moved a little away from those languages and are going now more towards the functional programming style. For one, it's often getting in your way that *everything* has to be (part of) an object. You need just a little function doing something? Well, first create a class and make it a member function of that class... Secondly, I now consider the class-based organization too rigid, because you can look at objects from different angles. You spend a lot of time and coding for enhancing/breaking/modifying objects because the class you (or somebody else) designed is not exactly what you need (and many of the mentioned design patterns are just for that purpose). And lastly, at least with the way the main OOP languages (Java, C#) are designed (shared memory between threads), you will never be able to write error-free, debuggable code for today's multi-core systems.

 

Bottom line: I would guess that many of those 57% disliking OOP don't want to think too much about structuring their code and just type away (which is bad once things get larger). But after doing OOP for more than 15 years, I think the OOP structure really can get in your way and you need something else, at least in addition.

 

Oh well, a lot of text and no clear advice... but I guess that just shows what a difficult question that is

[ZioRed]

I completely agree with Naughty Alien, even if I never used procedural programming in my life for anything (except Qbasic), neither in PHP4 (or may be I came to PHP4 when they added classes), neither in LE2 (since I used our C# bindings there). Also I don't know where ypu found "57%" statistics, it sounds quite strange (or are you considering C-guys or nostalgic ones), I personally never found one only dev who liked procedural over OOP (but it could only be "lucky").

[cassius]

Some interesting replies. I am using c++ in a procedural way for my current test project and have not considered lua at al.

[Josh]

The good side of OOP is it makes things more compact. Instead of writing this:

SetEntityPosition(entity0,GetEntityPosition(entity1))

 

You can just write this:

entity0->SetPosition(entity1->GetPosition())

 

Inheritance and function overloading are a requirement for a complex program. I couldn't write Leadwerks without those things.

 

The dark side of OOP is when people try to apply ideas blindly without considering their practical implications. When you see classes like WorldManager and ObjectInitializer, that is usually a sign of inflexible code. In my view, OOP code should try to make classes as self-contained as possible.

[Furbolg]

In my view, OOP code should try to make classes as self-contained as possible.

 

Sorry but this really sounds funny to hear from you, because you dont use private, protect etc.

[Rastar]

Sorry but this really sounds funny to hear from you, because you dont use private, protect etc.

 

But there is a difference between self-contained in the sense of cohesion, making a class not overly dependent on others, and encapsulation, hiding stuff that other classes shouldn't see. I guess Josh was referring to the first.

[Josh]

 

 

Sorry but this really sounds funny to hear from you, because you dont use private, protect etc.

Some members are needed by other classes in the engine. Some aren't. Sometimes what needs to be accessed changes. Because there's no consistent rule, I'm not going to waste time trying to hide some members, and then have to explain that others are public, but should not be accessed. And there's no way I am declaring an extra function and making a call to it just to read a simple variable. That throws away one of the main benefits of OOP...the fact that objects can have members.

[Thomas]

And there's no way I am declaring an extra function and making a call to it just to read a simple variable.

 

I absolutely support that (but well, I'm a C programmer and hate oop really a lot).

[ZioRed]

And there's no way I am declaring an extra function and making a call to it just to read a simple variable. That throws away one of the main benefits of OOP...the fact that objects can have members.

This is a personal thought about OOP, that of course I completely disagree for the reasons I explained in another thread, but this is your product and your programming style so if you find it good then I'm fine too (may be a little estranged, but fine).

 

PS: the members don't exist so you can write less code, if we're talking for example about a variable that is used in a loop to update a position then you're right but if I can mess your class methods by just changing a member that you set public in your World class and by doing so your class fails or crash then you should agree that it's definitely not good (it's just an example, I don't know for example if changing or deleting "entities" or "octrees" in the World class would cause crashes or something and the fact that "I should read the documentation" is definitely not a good reason if you allow me to do [also because the documentation is a little..ehm..well let's say not exactly complete]).

[Rastar]

By now I consider that a lacking feature of many OOP languages. Some languages (e.g. Scala on the JVM) have an identical syntax for a plain member variable vs a method access. So the client just calls myClass.point and is unaware whether he is just calling the variable, or if a member function does some magic instead. As a class designer, you can just start with the plain variable, and if you later need some code around the access you create a method instead, with client code being unaffected.

[ZioRed]

Yeah I don't like to use methods where a member is more suited, that's why I love C# and its Properties much more than C++, though in C++ we have usually getter/setter methods so I'd just prefer to stick to them. But it's not a problem (if you know what you should or shouldn't do, that's why a strong documentation is definitely needed in these cases, especially for mentioning what members you shouldn't touch since they're public [and I'm used to read through the headers when the documentation lacks something]) or big criticism, it's just personal taste.

[Rick]

This is a dangerous thread

 

My view is that the rules and guidelines for OOP are put in place for a reason. Not following them will come back and get you at some point in your development. It may be manageable in your eyes and then that's fine. However, it's important to know why these rules exist. Experiencing them first hand will often have you an advocate for them. Not experiencing them will often have you fighting against them because of the extra code you have to write.

 

 

The dark side of OOP is when people try to apply ideas blindly without considering their practical implications.

 

That's pretty insulting to people who know why these guidelines exist and choose to use them. If a big studio buys LE 3 and has the word entities list (as just an example) accessed and use all over their code and then you realize you need to change that variable or expose it differently for 3.1 because you missed something or changed a process or whatever, and you do an upgrade that breaks this usage and the studio has to spend time and money to fix that in their code, and they write you a nasty email, then you'll experience why it's better to not expose variables directly and to not break your interface if you can absolutely help it.

 

Maybe that'll never happen. Maybe it will and their confidence in LE will be out the window. Who knows. It's important one knows the risks and they decide if it's worth taking or not. That's all it come down too really in anything in life.

[ZioRed]

Of course, as most of times, I totally agree with you Rick, we're on the same wave around that. I tried to explain the same concept, though I probably was felt like an attacker to a programming style (when I'm definitely not).

[beo6]

I would agree to that, but i am sure there are reasons why it is as it is.

 

And maybe the undocumented methods are there because they could change later.

 

I too sometimes changed a method to public so it could be accessed more easily.

 

 

And since the LE structure looks easy to understand i wouldn't worry so much and i think it also adds more flexibility for us since we can also access members that would be inaccessible otherwise since the engine is closed source.

[Josh]

BlitzMax had a more sensible private/public scheme. Private made variables private within the static library, not within the class.

[Mumbles]

My take on it has always been, only really C++ does it right. Not everything is an object...

 

Why have an "engine object"? Fine if you're going to create more than one instance at once, but, I can't really see a reason for it.

 

My view has always been that engine functions are procedural, and things like sounds and models are objects. Mix and match and get the best of both worlds...

 

 

The singleton class is a complete oxymoron. Do you ever see "classes" in school with just 1 kid assigned to them?

[Roland]

Everything in this world should be taken with some sense, this holds for OOP also.

[beo6]

you are thinking of a class like a school class?

 

theoretically there could also be a school class with only 1 kid. Maybe a private teacher or something like that.