Does anyone actually use OOP unironically?
Why would I ever want objects for storing data when I can just create a multidimensional array?
Thank God C still exists
I wasn't going to respond to your obvious bait, but then I saw your triples and figured might as well.
I used to hate OOP because of people who used it badly (like the professors who taught me it.) But like any programming paradigm, the truth is it has its good parts and bad parts. Inheritance is one of those parts to stay away from in my opinion.
One of the nice parts is that it helps you logically organize your code. It also lets you make data types and attach functions to them and reuse those functions logically for other data types.
If you're not just baiting, you're doing yourself a major disservice by dismissing an entire paradigm. Even if it sucks overall, there's still a lot you can learn from it.
OOP is good for business settings so people don't have to read through miles of someone else's thoughts. They can just get chunks of code as classes and literally fit them together like a child would fit Legos together. They can also break projects apart into pieces without looking too deep into the code to better understand how it all fits together. It's useful that way.
However! It's a cluster fuck to do when you're working on your own and completely unnecessary. Making 20+ java files linked up together to run a simple program is asinine.
It can make the world easier to describe.
A simple example is data structures.
Your example was a two dimensional array.
Say you want to make calculations with a matrix.
Having matrix class could be benificial.
Eg. you have the data stored in a two dimensional array.
Then you would like to make functions like matrix multiplications, determinant, inverse, transpose etc.
In c++, you can overload functions such that mat_a * mat_b becomes the matrix multiplication you wanted.
This is useful abstractions as the people who work with the code knows what multiplications does and all they have to do is multiply two matrices.
Now this is also useful when you have to represent other stuff like nodes in a graph or make abstractions in a large application.
>Making 20+ java files linked up together to run a simple program is asinine.
At an internship one of the programmers at the company did that. Some kind of parser program he wrote more or less on his own.
When he showed me the program, it took him about 10+ hops to get to a part where actually reads in a document. He got lost in his unnecessary layers upon layers of abstraction.
Shit was hilarious and sad at the same time.
that's not what OOP is for - structs can do that in C.
it's a little over rated but they're for *predictably* inheriting attributes and operations.
like... if you're making a game. anything subclassing type Bird can fly() and poop() so when you implement Duck all you need to do is implement quack() and when you implement Chicken all you need to do is implement cluck().
This. OOP allows you to just import classes and call on a few public methods, the abstraction makes it easy to fit into other projects. This means that multiple people can write their own classes and fit them together into some larger program, without having to understand the details of their implementations. And if everything is properly organized/encapsulated, you don't have to worry about your code ever fucking with code someone else wrote.
I'm currently studying software engineering(full time) and the only language offered is Java in OOP. Not kidding, this other location of the same school instead offers C-Sharp, should I switch from location? C-Sharp is almost just as shitty
That doesn't really work in practice. There are too many cross-cutting concerns like logging, authorization or error handling that create dependencies to the program the class resides in.
Additionally, there can be many traps like hidden dependency chains inside of classes (class A calls class B, which in turn needs class C), so in the end you always pull in big parts of the application.
If you want to make a class portable across application you usually always end up creating a whole library anyways.
Lol, OP never went past fizzbuzz.
When you have a let's say betting application with 20 different view, and a viewmodel for each of it, you'll be running with arms wide open to OOP.
For example, each ViewModel implements ViewModelBase that has a virtual method called Initialize() that sets back the state of it to the one it was when you started the application.
So instead of doing:
. . .
all 20+ ViewModels
. . .
You register them into a IoC container that keeps track of all ViewModels that inherit ViewModelBase, and since they all override Initialize() you have a one liner when you want to reset the application:
this.EachViewModel(viewModel => viewModel.Initialize());
And that's just one tiny example where, if you abstract properly, with 2-3 extra lines of code, or one Interface/Base class, you can save tons of boilerplate code.
Inheritance is clean from a design standpoint. For instance, I'm writing a football game. There are plays that you can call, each of which behaves differently but still shares common functionality. I can write common functionality once in the super class and write more specific implementation in subclasses. When these classes get used I can just keep a generic Play object and rely on java to call the appropriate subclass methods at runtime.
Except instead of running those plays on a real field, you have the professionals do them on the sidelines, and just have some fans watch them and try to replicate it in the field.
even the simplest java programs are bloated as fzck and take "ages" (not really but compared to C applications) to load!
Then print aome stuff and exit
Actual 40 lines mini "project" in Netbeans (80k of storage, 2MB ram use, for printing binary numbers converted to dec. numbers, fuck java!)
>composite types = over complicating
>keeping track of memory alignment manually, pointer arithmetics and casts everywhere = simple
>doing expensive conversions from and to string representations = simple
I hope I'm being trolled.
Using a struct with 3 members (they could be pointers too). The space requirements will be larger, but well yeah. It will also need lot more memory access, due to dereferencing all those pointers.
Void pointer array is a solution too.
You could also just implement your own objects. Take a look at some time how inheritance (especially shit which has the virtual keyword in it) is done in C++ under the hood. It's just nice that the compiler and the language abstracts it away, but it's not a clean solution in the way you might think it is.
OOP's main strength lies in generics, and abstract interfaces. These concepts can be implemented in a language like C, but it requires more work on the programmer's side. A C-like language with a standard multithreading library, and a small subset of C++'s features would be a really good systems programming l
Depends on the language C++ terms something like that, but there's a difference between a POD C struct and between an object defined using the struct keyword in C++. Struct is simply an aggregated type.
>Struct instances are objects.
That's like saying ints are objects in the C world, where they're not.
Humans vs machines, anon.
imperative is far better for machines because of how they work, while oop is better for humans because of how we work
just like you're not going to write a script in c++, you'll just use python or bash, you should use the adequate tool to the task
imperative languages are better for performance, OOP are better for complex programs that have to be mantained by different people
needlessly moving one problem (types) somewhere else.
Creating useless multiple functions that jusr call other functions and so on.
Either my teacher taught nonsens, rhe examples are srupid or I'm too dumb to get the advantage of interfaces.
Yes, but as I learned it, it's effectively just a THING between 2 classes, that does not help getting the hierarchy right.
So it might be the example, why I don't get how interfaces help
Some other guy, but I always found imperative + "functional-like" stuff easier + a bit of OOP better and that's how I write some code. I never liked too much OOP or it's mindless using.
Imagine a game where you have different creatures, but want common commands to them to follow. Like go there, attack that, how much hp do you have? how much armor do you have? where are you? is x hostile to you? equip that if you can! use that item! what's in your inventory? etc....
Now you define these as functions of the interface and all creatures capable of doing all these functions will implement this interface. You can also allow implementing the interface when it can't do it so it will give you an error (like an animal can't equip a longbow) through a well defined interface. Yet the class of these creatures are really different. For example one to perform proper animations and behavior might inherit from the FourLeggedAnimal class or the PrimitiveCreature class and another inherits from the UndeadNPC class which has a vastly different AI and capable of equipping and using items. (Inheritance is not always the best way to do things, composition is sometimes a lot better, but it makes a good example for interfaces, even composition does) The thing is you don't need to know the actual class of the object. As such you can store them in the same array/container/whatever. When you need to know it's actual type you could have your interface could have a function where each object gives back it's actual type then you know how you can refer to it properly.
When you do composition you have classes do specific functions. When a creature wants that function it will have that class as it's member. So in that case you will use interfaces to get information about whether that creatures has for example an instance of MovementModelFourLegged in it. Then you get that subsystem and give it specific commands which it will apply to what it's part of.
We all do that sometimes. No worries mate.
Not talking about type system. Talking about code structure and design. I worked as a Web developer. We used a MVC pattern using objects.
Nice trips, but even you know C fags don't store data in multidimensional arrays but in objects called structs and then make functions prefixed by the name of the object they manipulate on.FAGGOT* OP = malloc(sizeof(FAGGOT));
int x = faggot_get_faggotry(OP);
/* notice how all functions start with faggot_ and pass OP as first arg? */
OOP just refines this abstraction by letting objects contain methods and letting objects contain methods and letting them clearly define what they manipulate and what they do.FAGGOT* OP = new FAGGOT;
int x = OP->get_faggotry();
/* We know OP is a FAGGOT and we know what he is able of. */
The abstraction is pretty much the same, It's just that C fags have to struggle doing simple tasks that OOP languages do easy like inheritance, polymorphism, encapsulation, etc.
> using "TYPE* name" declarations instead of "TYPE *name"
C's pointer/array declaration syntax (mimicking most common accessors, splitting them from the base type in multiple declaration statements, etc.) is retarded and confuses a lot of new programmers, but it's even worse to misrepresent what the language is doing.
> int* x = 0, y = 1; // thanks, Ritchie, for making this possible
>he uses "TYPE *name"
Raging C fag detected.
It's alwaystype identifier;and in this case it's pointer type regardless that C syntax doesn't really see it like that.
But if you're concerned about new programmers though just teach them to always do this:int* x = 0;
int y = 1;
>defending OOP practices this hard
>calling programmers "C fags"
>being this designated
please stop talking about C you clearly know nothing about and go back to Java you curry eating street shitter.
>and in this case it's pointer type regardless that C syntax doesn't really see it like that.
In C, being a pointer/array is explicitly part of the identifier, even if it makes fuck all sense.
the only thing worse than being retarded is being retarded and trying to hide it.
> i'm too dumb to understand the standard paradigms of OOP
> OOP is shit
Well yes, you don't need classes and OOP for you fizzbuzz in your mom's basement, you fuckin fat neckbeard.
You counter that by not making classes dependent on other classes. Make each one self contained and able to interact with another class, but not dependent on it. If dependency on any outside class is a must you damn well better outline it and put it in red ink at the top of your logs you share with teammates.