19 comments

0

https://www.invidio.us/watch?v=_xLgr6Ng4qQ :

Handmade Hero | Private Data & Getters/Setters (Epic rant!) - YouTube


This has been an automated message.

0
0

Because properties are mapped correctly when the class is mapped while instance variables are not.

This guy is a fuckin’ idiot. “Let’s make everything public” completely ignores the first main reason for object oriented programming.

0

I bet he would want to make everything static too so there would never be a need to instantiate a class object. Combined with everything being public, this would completely destroy OOP.

0

That's a feature, not a bug. OOP is garbage.

0

Sperg much? Jesus.

0

Why haven't I thought of that before? Probably because I don't want to thrash the web server.

0

Object oriented programming is trash.

0

It's a fad like color TV and radio ads.

0

It’s useful when the project calls for it.

0

Found the journalist.

0

what a dumb shit

0

You don't want to change the interface for a bug fix. He's fired.

0

That was refactoring not a bug fix.

0

The simple example in the video was a refactor. What if you need to add a getter or setter as part of a bug fix?

0

That was exactly what he was demonstrating... Any technique is going to have an appropriate context for use. And he made sure to provide that context and a method of handling exceptions to the (his) rule. What more do you want!

0

If you add a getter or setter, making the member private, as part of a bug fix you change the interface. This is OK for a major revision, not for a bug fix.

0

This guy is a moron.

When he want's to introduce a getter later, he has to change all the uses of that variable and potentially breaking code of your customers if you're programming a library someone else uses.

I agree, it's a lot to type, but that's a mistake of the langauge.

In C# it would just be

public int TheData { get; set; }

You can use it like a normal variable.

You can later implement logic into the getter/setter without Breaking any code.

You can have a breakpoint in the getter/setter, which helps you to debug why and where the property unexpectedly gets changed.

0

The title should be "Getters/Setters in C++ is an awful programming practice.

Any other language Getters and setters should be used. I had this discussion with a colleague that wanted to improve performance by converting it to fields in C# but I told him it has no impact with modern C# compilers.

Now back to C++. he is an idiot even in C++.

He is right that in C++ you get faster execution and less typing if you use struct and fields. It tells the compiler to optimize even further than the normal optimizing. But as a general rule it sucks!

I did outperform in OOP even hardened C++ developers that developed in pure C. Not only did I outperform the C developer I developed my code at a faster pace.

The OOP development in C++ gives me a very good way to scale my application without losing development time. Using struct or using a class is at assembly level exactly the same thing. in both cases you use the first parameter to pass on the struct/class.

He is an idiot because he thinks he has the answer to all solutions and anyone that thinks differently must be fired. But different techniques are needed for different projects:

  • Is this code intended for an UI?
  • Is this code intended for high speed calculations.
  • Is this code to be developed for a faster response cycle?
  • Is this code developed with very small memory footprint?
  • Is this code developed for multi-threading?

The advantage of having a struct over a class is that you can very fast memcopy it when you need to clone. In multi threaded operations that needs a massive number of threads you can put this struct inside your class and have minimal locks time when you memcopy the struct instead of field by field. Bang! The advantages of OOP design that scales very well and fast speeds by this internal struct.

People should really stop thinking that software is a set of design rules, patterns and logic. It is a living entity that should never be restricted to design rules and patterns.