Learn to Code via Tutorials on Repl.it!

← Back to all posts
Introduction to Object Oriented Programming.
JustAWalrus (1192)

Introduction to Object Oriented Programming.

Hey.

So I need to write a tutorial.

Otherwise I will fade into obscurity.

So let's get into Object Oriented Programming or OOP.

What is the big deal with OOP?

Mostly, OOP just cleans up your code. It looks nice and is easy for others to work with. It can also make you write code more efficiently.

You are hiding all your complex code behind a wall that can be accessed easily.

For example, if you were writing a game engine you'd want people to be able to make a sprite easily with your library. OOP helps with this.

OOP Fundamentals.

OOP mainly consists of three general principles:

  • Classes
  • Methods
  • Attributes

Let's break these ideas down.

Classes.

This is the most prominent idea in OOP. Classes are kind of like a car, an empty slate for an object. Each car is generally following the same principles, but, they can be made differently. When you create an instance (kind of like a model of the car class) you are making a different kind of object that follows the general principles of that class but can be made differently. Take the int data type as an example, it follows a few principles like the value has to be an integral value and when added it returns the sum of those two values, but, it can have a different value, scope, etc.

Methods.

Think of the car, the car can be used to do many things (drive, repair, etc.). Well those things the car can do are kind of like methods! And these methods are basically functions! Think of the int data type again. The function toString() for the int data type may be a method of that data type.

Attributes.

Think of the car again, the car can have various attributes and so can a class instance. In the car example, this may be the engine, speed, etc. These things can be used in the methods to do various things.

Conclusion.

If you enjoyed, upvote.

It's really very simple.

Comments
hotnewtop
JaneJLocane (1)

It's interesting! Thanks a lot!

JeffThorsen777 (1)

Thank you, very interesting article. I was writing a term paper on programming. I tried to find a lot of material, but I could not arrange the work properly. I was recommended this article to inquire about services that help students in such matters. I decided to consult on my coursework and did not regret it. I was able to turn it in on time. And the topic of programming was revealed in the work maximally.

DungeonMaster00 (189)

make an f# tutorial next

Jakman (451)

Talk about FP and let the pykids have their minds blown.

Highwayman (1501)

Otherwise I will fade into obscurity.

bruh.

EpicGamer007 (1751)

Good job!(me crying because my OOP tutorial sucks compared to yours). I would suggest going over good OOP principles and inheritance.

HahaYes (1869)

well... I'll write a really long tutorial about classes. But classes suck (C GANG)

HahaYes (1869)

@Wuru tbh as a C++ and C user I've never liked classes but its ok

JustAWalrus (1192)

I use C++ on a daily basis and I praise classes. @HahaYes

HahaYes (1869)

@Wuru yeah, I like C++ but C is faster but less safe. C is like a F1 with a rocket engine strapped on the back without a steering wheel, C++ is like a nascar, Python is like a honda civic 1 cylinder car

Highwayman (1501)

This I find interesting. How, very specifically is C supposed to be faster as a lang than c++? Shouldn’t they be of the same speed? Like think about it. Write the exact same program in C and C++, compile the two, and run. How is the C one supposed to be any faster if it’s the exact same code? @HahaYes

DynamicSquid (5023)

@Highwayman true, C isn't any faster or slower than C++. also a bunch of high reputation users on Stack Overflow also say the same thing, so it must be right: https://stackoverflow.com/questions/6955114/is-c-notably-faster-than-c

HahaYes (1869)

@Highwayman C is faster because C++ is based on C

Highwayman (1501)

mmmm bad logic, man. bad logic. @HahaYes

firefish (953)

rethink your decision. @HahaYes

Jakman (451)

@HahaYes Represent. (C GANG)

Jakman (451)

@Highwayman @HahaYes C is very slightly faster than Cpp because of the amount of features that C has compared to Cpp. Since Cpp is a blatant upgrade of C with a few slight differences, C will obviously be a little faster since it has less to compile and the computer has less to interpret as opposed to Cpp

Highwayman (1501)

@Jakman

Since Cpp is a blatant upgrade of C with a few slight differences

um. right there. that's exactly why it's as fast. it has all the same stuff, and they are both compiled so the implementation doesn't have to change. like honestly are you gonna tell me that i + i is suddenly supposed to take up more assembly instructions in c++ than c? how would that even work? come on. that's just not a thing. right now the only thing I can really think of that actually is faster in C then in C++ is VLAs bc C can allocate one on the stack instead of the heap, which is always faster, but again you can just directly implement that with inline assembly, so no.

Another thing I want to talk about is the std libs for C and C++.

Yes much of the C++ std lib can be slower than it's C counterpart, but C++'s lib is probably a lot bigger than C's, therefore reducing the amount of naive code written.

lastly, let's talk about C++'s additional features vs C's.
C++ has ever increasingly provided a plethora of methods to evaluate operations at compile time. This will of course end up completely erasing full blocks of code and their associated bottlenecks and such. constexpr. consteval. templates. suddenly you don't need a single bit of extra data. I bet you a billion dollars that you could write a faster and type safe version of C's printf in 20 seconds that has no need for these extra code steps that have to determine the type. again, C++'s extra features coming to the rescue, saving runtime cycles. here, let me do it rn.

// faster because less naive code / SSO. automatic plus.
#include <string>

#include <unistd.h>

// we no longer have to determine type. automatic plus.
template <typename... Args_t>
void printf(const std::string& fmt, Args_t ... agrs) {
  // if we don't need to format anything, then we will never even check the args and we don't have to check fmt for the args either. all of this is decided at compile time. automatic plus.
  constexpr if(sizeof...(Args_t) == 0) {
    // fmt.length() probably just straight returns one of fmt's member variables. no need to find out the length, less time spent on crap like strlen. automatic plus.
    write(fmt.c_str(), 1, fmt.length(), 0); // (plz excuse me if I messed up the function call. the point is just to get the idea right.)
  }
  else {
    std::string result = fmt;
    // the correct version of to_string is decided at compile time again because args is type-safe, so less time is spent on type deduction. automatic plus.
    std::string strs[] = { std::to_string() };
    std::size_t full_len = result.length();
    for(auto it : result) {
      if(*it == '%') {
        if(*(it+1) != '%')
                                 // vvvvv there's a better way of writing this, but im lazy.
          result.insert(it, strs[ ((&*it)-(&*result.begin)) ]);
        else
          result.erase(it);
      }
    }
    write(result.c_str(), 1, result.length(), 0);
  }
}

as you can see, it gets a lot of advantages out of C++ in just this single little printf function built by the extremely naive programmer that is me. imagine if someone who actually knew what they were doing wrote it out... boom. C++. take advantage of it people. :)

anyways. my point is here that if anything mst of C++'s extra features are only going to help you, and of course you can still just forgo those features, write the SAME EXACT CODE AS C IN C++... and get the same performance.

I'm still not convinced by any of all y'all's weak reasoning. There actually are plenty of things you could say I'm sure... but so far I'm just seeing empty faith n' stuff.

oh, also, the C and C++ compilers also don't "interpret" anything. the extra or more prolific code will be compiled all the same and run fast all the same. am I going in circles? I think I am...

Highwayman (1501)

@Jakman actually after rereading I retract my very last statement somewhat. I now see that you meant it will produce more assembly instructions for the cpu to decode. fair point. I see what you mean.

Jakman (451)

@Highwayman you have a well oriented essay. I am just saying that the Cpp parts of a program when added to a pre-existing C program make it very slightly slower especially when the constructs of classes and encapsulation are added to the program.

Jakman (451)

@Highwayman no offense has been taken

Highwayman (1501)

@Jakman

you have a well oriented essay.

lol thanks. It just kinda ended up that way. I guess I have school on the brain or something.

the Cpp parts of a program when added to a pre-existing C program make it very slightly slower

hm. well ok that's fair. I know there are some Cpp features that can slow down code, but as I said and (attempted to) demonstrate earlier, there's plenty of other Cpp parts that speed up execution. I'd think in a well formed and well optimized Cpp program, it could execute just as fast as the C counterpart because the advantageous and dis-advantageous features would cancel each other out, yes?

especially when the constructs of classes and encapsulation are added to the program.

mmm I'm not so sure. a class method is just going to be reduced to some form of ret_t func_name(class_t this, args...) at the end of the day, and grouped data is also a thing in C with structs, so it's really gonna always reduce to the same methods, and of course that just means it's gonna have the same speeds.
Encapsulation though... hm. I'm not really sure how that would really slow anything down... that's just basically an extra step for the type checker I'm pretty, so it seems like that'd be just a compile time lag, not a reduction of runtime speeds...? how would it slow down execution?

no offense has been taken

I'm glad :) I enjoy convos like this idk debates are fun.

Jakman (451)

@Highwayman i feel the exact same way. nice chat

HahaYes (1869)

@Highwayman you should check out my java tutorial. Thanks for the paragraph tho

JustAWalrus (1192)

Feel free to stop advertising :) enjoy the report! @HahaYes

DynamicSquid (5023)

I'm getting started on learning C right now, mainly because C doesn't have classes, so it should be really interesting. I've heard that C people would like to see OOP die in a hole, but, like, they do have a point. Classes can sometimes get too messy

firefish (953)

OOP mainly consists of three general principles:
Classes
Methods
Attributes

You do mean Properties instead of attributes.

Highwayman (1501)

No he meant Vdrjgswujdesssswessas
@firefish

firefish (953)

@Highwayman I don't speak ERdjkdgfdkgshkjfgh.

Highwayman (1501)

A r e y o u s u r e gddfwwgbioogsswasa @firefish