Other Examples of good OOP code

blind0ne

blind0ne

Hello,

Here is the question itself - I need to show (and see) examples of really good OOP code that will satisfy nearly all object oriented concepts and will be actually usefull in terms of functionality. It's imortant for me, it shuld give good impression for people how harass my code and tell to be more object-oriented, but my code itself is more scriptting-stylish and it defennetly won't satisfy anyone who in OOP

Please help me, it will save my life, literraly.
It's not for interview, just the question of lifetime depression.
 
Uh? OOP is no "silver bullet". If you're looking for "good" examples, first tell which language. The concepts are similar (and some can be used even in languages that don't support OOP themselves), but the code will still look very different.

More importantly: OOP has many concepts that easily lead to BAD code when overused or wrongly used (like inheritance, only ever use it for real "is a " relationships, never for code reuse – for the latter, "composition over inheritance" is the golden rule). So I'd say it's impossible to show "good" OOP example code. What's good depends a lot on the real domain that's actually modeled.
 
I bet, John Carmack and the rest of the DooM 3 fellas knew what they're doing. You bet!
Therefore, I think that should be a good example, a good starting point, a very hard one!

C++/DooM 3:
github.com

GitHub - id-Software/DOOM-3: Doom 3 GPL source release

Doom 3 GPL source release. Contribute to id-Software/DOOM-3 development by creating an account on GitHub.
github.com github.com

C/DooM:
github.com

GitHub - id-Software/DOOM: DOOM Open Source Release

DOOM Open Source Release. Contribute to id-Software/DOOM development by creating an account on GitHub.
github.com github.com
 
I notice that much "non-object oriented" code is still actually dealing with the concept of objects. Usually just written quirky and with not-quite perfect encapsulation, etc. Some formal examples of OOP.

Object oriented C++98 (non-exception safe)
Code: 
Employee* e = new Employee();
e->setName("Bobby");
e->generateWage();
delete e;
Object oriented C++0x
Code: 
std::shared_ptr<Employee> e = std::make_shared<Employee>();
e->setName("Bobby");
e->generateWage();

Object oriented C
Code: 
struct Employee *e = EmployeeCreate();
EmployeeSetName(e, "Bobby");
EmployeeGenerateWage(e);
EmployeeDestroy(e);

I would say that OOP in game engines or simulation projects is not great. You end up "chasing pointers" too much. Consider:

Code: 
getEntity()->getTransform()->move(x, y, z);
Following the pointer to the owning object, only to move down to a sibling component, only to change positional data is a little bit wasteful if you imagine that *every* object in the simulation is likely doing this.

Likewise with scripts, you often want to solve the task with as little code as possible (to make it easier to maintain / understand later on). So you don't want all this boilerplate OOP code creating these big hierarchies of objects, only to do some (generally) minor processing, only to tear it all down again.
 
What matters most about programming is getting your job done. It doesn't matter, if you do this in OOP or another paradigm like functional programming.

People who demand you to do it in their way, if it is your own project, often have no idea what they are talking about.

Aside that I do consider OOP at least as overrated, if not overhyped in the past. It's now 35+ years old, came with many promises and most of them are broken.
 
OOP is a way of thinking and means that you break down the problem you want to solve into actors with properties.
Looking at UML class diagrams can help to understand the concept.

Since the thread has a PHP label i will give an example for an online shop.

A customer is an object. Properties would be first name, last name and a reference to an address.
The address of the customer is an object. Properties would be city, street, country.
A t-shirt is an object. Properties would be size, color, price.
An order is an object. Properties would be customer, date and a list of t-shirts.

Now create classes for all these, create objects from these classes and try to order a t-shirt. :cool:
 
OOP has gone out of fashion to a large extent. It was all the rage ~25 years ago and unfortunately it got badly overused. Everything was an object, even when there was no real relationship hierarchy. That's a maintenance headache as inheritance is a very strong dependency. If you have a library with lots of users you aren't free to go changing the base classes (unless the library was designed to isolate the virtual-ness, often not the case for older code).

Given the choice I usually go for static polymorphism (templates). This can be a bit more difficult and cause code bloat but it won't give you dependency grief and the code is usually faster.
 
From Stroustrup interview: "Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient."


This is also good: "C++ is dying off now, but programmers still get high salaries - especially those poor devils who have to maintain all this crap. You do realise, it's impossible to maintain a large C++ software module if you didn't actually write it?"
 
alan-kay.pngbjarne-stroustrup.png

stereobooster.github.io

Two big schools of Object-Oriented Programming

TL;DR There is no one “canonical” definition of OOP. There are at least two of them. From my POV there are two big definitions, which deserves separate names. I named them after biggest advocates. Those two definition have some differences and some commonalities. I was about to get into another...
stereobooster.github.io
 
You must log in or register to reply here.
Back
Top