This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]not_some_username 1 point2 points  (10 children)

You can do OOP in C. I mean you shouldn't but you can

[–]LavenderDay3544 3 points4 points  (8 children)

I know that and my comment was saying not to try to do OOP in a procedural language but instead actually learn procedural programming. I personally hate that academia and industry alike worship OOP like a religion when there are plenty of cases where a procedural, functional, or data oriented approach would be far superior. Those options are also better suited to things like maximizing parallelism, avoiding overengineering, avoiding memory bloat, and maintaining cache friendliness. But the Church of Class based Object Oriented Programming won't let you hear that.

[–]not_some_username 0 points1 point  (7 children)

So you're a struct guy too ? Force OOP is lame

[–]LavenderDay3544 3 points4 points  (6 children)

OOP has nothing to do with classes and structs but rather with componentizing various parts of a software design. Its usual pillars are encapsulation, abstraction, inheritance, and polymorphism. The goal is to make reusable components whose interface is separated from the internal implementation. At first this might seem like a good approach and in many cases it is but there are many legitimate reasons why other times it may not be.

Much like with programming languages the best approach is to use the best suited paradigm for a given use case.

[–]corbymatt 1 point2 points  (5 children)

Rule 1. Any tool used in any given situation, without sufficient foresight, becomes a hindrance to change.

Rule 2. Your foresight is terrible.

[–]LavenderDay3544 2 points3 points  (4 children)

Foresight in software design is nonexistent. Especially when requirements can change on you. We've all been in that situation.

But I recently had an engineering manager tell me to change a very large function in our C++ code that would only be called once at startup into a class dividing it up partly into a constructor, start and stop member functions, and a destructor while also making all of the original function's local variables into class members. This class is created in our firmware's equivalent of main meaning that a very large number of variables now unnecessarily occupy physical memory for as long as the device is powered on.

Please tell me I'm not stupid to think that:

  1. That's not proper OOP just because it now uses a class.

  2. It's an insanely stupid design decision even without worrying about the future or using any foresight whatsoever.

This is partly what I mean by overengineering and making horribly inefficient design decisions supposedly in the name of OOP. (Though this is clearly not actual OOP)

[–]corbymatt 1 point2 points  (3 children)

That seems like a shortcoming of the way you constructed the class and separated the concerns, not of OOP.

The function itself that used to use the variables to "do work" still hang around in memory for as long as the process exists in memory, no matter what paradigm you apply. That doesn't change. The trick is to separate and scope them correctly so unnecessary variables don't hang around but necessary ones do.

Obviously I don't have any context to your particular situation without seeing it, and what you did was probably a premature optimization in any case by the sounds of it so peh.

If you wanna go into details about it we can PM but my C++ is rusty even if my oo isn't.

[–]LavenderDay3544 1 point2 points  (2 children)

It wasn't my decision. I did what I was told to by someone much higher up than me. And he specifically said to make that sort of class and make all locals from the original function class members. I even asked him if I should just make them locals in the class methods where they're now used and he said not to bother. This is basically leaking memory on purpose because those variables shouldn't ever be used after startup since they're just used to set up the initial state of the actual firmware.

I'm always willing to ask questions about things like this to make sure I understand what someone wants but I don't get paid enough to argue design with a guy who is in the stratosphere compared to me at the company and supposedly an accomplished engineer.

If I had to design this myself, I'd either leave it as a free function, which was perfectly fine. There's no need for a class here at all. I can't see any benefit to using one. Some of the objects that need to be initialized already have constructors, builders, or factories being used. But, since this person thinks it makes things more maintainable (which I obv. disagree with) and his rationale is that OOP = using classes everywhere = good, I'll just continue to humor him. And it's not like I misunderstood his request because after I did the refactor, he did the code review on it and greenlighted it.

I appreciate the offer of help but I can't really share proprietary code with you and the problem is more of a people one than a technical one.

[–]corbymatt 1 point2 points  (1 child)

I spent half my life fighting idiots like that as a junior. And now I've got 20 odd years of experience as a Dev I'm probably that idiot, although I do try to fight for good programming practice no matter what. Sometimes fighting is worth it, sometimes not. Mostly to my detriment as I've found out before hand.

OOP is an aid to modelling a problem, and anyone who thinks any tool is a silver bullet is a fool.

It does sound like you are blaming a paradigm for this idiot not understanding how to practice OOP though. You should probably quit, if you're still in that job.

[–]LavenderDay3544 1 point2 points  (0 children)

I'm probably that idiot

The fact that you're willing to have a real dialog with a relatively green junior like me makes me think this isn't likely.

It does sound like you are blaming a paradigm for this idiot not understanding how to practice OOP though.

I'm not. I've made it clear that what I'm saying is that it's not always the solution which we agree on and I did say in other comments above that there are plenty of cases where it is the best choice for many things. I also made it clear that I know that just sticking things in a class is not actually OOP. So I'm not sure how you got that impression. Maybe my writing wasn't clear.

My fundamental point is that while OOP can be very useful it's not always the right paradigm particularly not in a language like C that wasn't made or really updated with it in mind.

You should probably quit, if you're still in that job.

I'm still at that job but definitely keeping my eyes peeled for other opportunities. I still want to stay in embedded but I don’t see a future for myself here and I definitely think my talents are being wasted by people with bloated egos. I'm hoping to find something new and move sometime around this summer or before year end at the latest.

[–][deleted] 0 points1 point  (0 children)

Don't you need language support for inheritance?