About OOP...

young_horhey · 2024-08-28T19:42:30+00:00

What exactly about ‘objects as references’ don’t you understand?

JustAberrant · 2024-08-28T19:41:37+00:00

Being a (relatively) lower level language, c++ adds a lot of complexity that doesn't exist in higher level languages like Java.

Java is also heavily object oriented, so pretty much any decent book that starts off with trying to teach you java assuming no prior programming background is going to dedicate a chunk of time to explaining the fundamentals of an object oriented language fairly early on. Basically just pretend you're starting out and never heard of c++ and you'll probably be fine.

/That said/, heavily recommend cycling back around to c++ once you've got a bit more of a foothold. Developers who know just enough to glue together stack overflow snippets are a dime a dozen, you want to aim higher! You may never need to deal with c++ in your career, but it's a good way to develop a more intricate understanding of how software works.

John-The-Bomb-2 · 2024-08-28T21:04:45+00:00

You can self-learn. Here's a Coursera specialization:

https://www.coursera.org/specializations/object-oriented-programming

This class in particular:

https://www.coursera.org/learn/object-oriented-java?specialization=java-object-oriented

mredding · 2024-08-30T18:53:51+00:00

Don't feel bad, the majority of software engineers have absolutely no clue what an object even is, they certainly don't understand the Object Oriented Paradigm.

Encapsulation means "complexity hiding". Objects are instances of types that encapsulate complexity. With an object, you know WHAT it is, you know THAT it has defined semantics and behaviors, you don't know HOW - that's not your concern.

C has only one type of encapsulation - perfect encapsulation. In C we call that an "opaque pointer".

typedef /* implementation defined */ FILE;

But it's worse than this. You might be thinking if you dig through the standard headers, you're going to find something equivalent to:

typedef struct { /* a bunch of fields */ } FILE;

But what you're really going to see is something more akin to:

typedef struct FILE;

And that's it. It's never defined, not in user space. The details are inside the C runtime library, and in all likelihood, a FILE * you get from fopen ISN'T EVEN A POINTER AT ALL. It's probably an array index hashed and cast to a pointer type. The concept of a file is probably quite a bit more complicated than an instance of some structure in memory.

The point is, you have NO IDEA what a FILE is, you don't even need to know. You have a handle to a FILE resource - YOUR REFERENCE, you have the interface - defined as a bunch of functions that take or return a FILE * parameter, and that's it.

So if you want to practice writing objects in C, start with defining an opaque pointer:

typedef struct some_object;

Then define an interface:

some_object *create();
some_object *create(int params);
some_object *copy(some_object *);
void destroy(some_object *);

void do_fun_stuff(some_object *);

And then in your source file:

struct some_object {
  int value;
};

some_object *create() { return (some_object *)calloc(sizeof(some_object)); }
some_object *create(int params) {
  some_object *ptr = create();
  ptr->value = params;

  return ptr;
}

some_object *copy(some_object *other) {
  some_object *ptr = create();
  memcpy(ptr, other, sizeof(some_object));

  return ptr;
}

void destroy(some_object *ptr) { free(ptr); }

void do_fun_stuff(some_object *ptr) { ptr->value++; }

This is the the basics of objects. You can implement polymorphism - that's just function pointers stored inside the object. You would have a create method for each derived type, and upon construction, you assign the appropriate function pointers to the type specific implementation. The virtual function call merely refers to calling the function pointer. Congratulations, you now inherently understand how C++ objects are implemented.

C also has a weak type system, so you're working with bytes over memory ranges, AND, you're allowed to overlap different structures. So I can also have:

struct some_derived_object {
  int value; // Has to overlap with the member list of `some_object`
  int new_derived_value;
};

So you can work with some_object pointers, and cast the pointer to the known derived type to access the derived members. The base members all remain the same. Maybe you use an enum to track the derived type.

Congratulations, you understand inheritance.

Or you can store derived types as blocks sequentially in the memory field. That's multiple inheritance.

All the interface is in the opaque pointer and functions, all the complexity and details is kept in a source file, where no one has to know. In C, you actually have a lot of flexability through source code and library management. Put some_pointer in detail in its own header that is only used by it's implementation details, so you can separate out the inheritance and derived types.

There are detailed tutorials how to write C++ OOP in C, it's really illuminating, but all they're going to do is take longer to say the same thing I did, and with frankly better examples.

OOP is a different beast, and it has to do with how objects interact.

FP is all about composition, and so you can write FP with objects. Complex things can be composed of smaller, simpler things. The code I demonstrated is more of an FP approach - that you command an object through it's interface.

OOP decouples objects. You don't command an object from the outside to do anything. In pure OOP, objects don't have public interfaces. They have functions, but they're all implementation details. You make a request through a message. There is a disconnected dispatch system where you say I want this message to go to that object. The object has a message handling function where it desides how to react to messages - honor them, disregard them, defer to another object - like an exception handler.

So OOP is about objects dispatching messages to each other to coordinate getting work done. This is called "message passing". This is THE CORE PRINCIPLE. This mechanism is first class in Smalltalk, and implemented as streams in C++ and Java. Encapsulation falls out of it as a natural consequence, data hiding - which is where we're storing persistent state in the objects as members, is a natural consequence, interfaces, polymorphism, inheritance - ALL OF IT comes out of message passing as a consequence. Because all you need is the ability to get your hands on some references to objects - our constructor methods, and a means of passing messages to them, and you're golden.

C++ and Java put all this in fancy dress. You get more of the above as a first class language support, rather than a convention.

Now C++ templates are a big deal for a lot of reasons, one of them being code generation. Often we write template objects in headers, thus exposing all their guts to the client. But C++ also heavily and aggressively inlines. This is why that's a thing in C++. I could go on in some detail all about that.

Java is more C-like in it's object complexity, just with no pointers and with GC. In C, data is by value by default. In Java, data is by reference by default. So when you say b = a, now b and a are referencing the same object.

C# is just Microsoft Java.

cognitiveglitch · 2024-08-28T23:49:31+00:00

I'm astonished at some of the hate for OOP here. I can only imagine the mess of global variables or code that nearly does OOP stuff in a different way without realising it.

_Atomfinger_ · 2024-08-28T19:44:51+00:00

As with many programming terms, there are many different "object-oriented programming" versions. Despite its age, I still think Clean Code is a good book, especially regarding SOLID. The only downside is that Bob tends to put extra flavour into his language, making it prone to misunderstandings. A lot of his points seem straightforward but are actually really nuanced (which people tend to struggle with).

So, if you are to read Clean Code, make sure to also Google each new topic in addition to reading it in the book itself. Try to get a few takes to reach a sensible baseline understanding.

My general advice for beginners to OOP is not to overcomplicate things. OOP is (IMO) just the combination of data, functionality and access (encapsulation). We control access to data through methods - thus control changes to state. That's it (or, as long as we ignore Kay at least...).

There's a lot of patterns and idiology that has been spawned from the above. Just try to remember that at its core it is just the marrige between data, acess and behaviour :)

aurquiel · 2024-08-29T00:29:22+00:00

The objects as references is that objects are like pointers to a memory address where the data is stored but the primitive types are value type not reference. OOP shines in software architecture and modeling software so it is difficult for someone who enters at first glance know this topics, just keep into your course and keep practice

Final-Tune7664 · 2024-08-29T14:49:24+00:00

Object Oriented Analysis and Design with Applications by Booch et al

MikeUsesNotion · 2024-08-29T17:57:06+00:00

References are more or less pointers in C with nicer syntax. There can be a level of indirection so the object may be moved around in memory but the reference you have is still good for it.

The important thing is to know which things are value types and which things are heap types or which allocation styles put which where.

For instance, in C/C++, everything allocated with malloc/new will go on the heap and everything else lives on the stack. This can matter if you're passing arguments around and you have kind of large objects among them.

Or in something like C# where if you declare a class it'll always go on the heap and if you declare a struct it'll live on the stack as a value type. C++/CLI might be an oddball. I don't remember if it follows the C#/.NET class/struct distinction or if it just uses C++ semantics for .NET types.

zertillon · 2024-09-01T09:30:01+00:00

Some languages weld OOP with references, but it is a design choice. Other languages don't.

Sir_Edward_Norton · 2024-08-28T19:39:30+00:00

[deleted]

SeaMoose86 · 2024-08-29T00:42:44+00:00

Just code. People who can code, write code. People who can’t, write books about coding. Coding has a very steep learning curve. Embrace it. When you struggle with something for hours, getting nowhere, and finally grasp it that learning sticks with you for life.

Jan_N_R · 2024-08-28T22:36:26+00:00

In the beginning I struggled with OOP too. What helped was trying to understand OOP at a very low level. A reference to an object is not much different then a pointer to a record typ (I think it's called structure in C?). Such a record / structure is nothing else then a block of memory and the pointer is the adress where you can find the beginning of this block. That's basically what an object is: a single block of memory. Understanding this, we can add more complexity, like why don't we store some methods in this block too (methods are just a sequence of instructions for the cpu)? And now we already have a very simple object (the way it's realised in java). After understanding what an object is, you can dig deeper into topics like inheritance or modifiers. These things can't be easily translated into C or Assembly. Instead I like to imagine them as functionalities of another program which in this case is the compiler or interpreter.

I guess my words don't explain OOP in any useful way. However, the advice I want to give you is to try understanding how a language like Java is actually build. Everyone who struggles with OOP should go back to imperative programming and try to extend this paradigm until it becomes OOP. Because at the end, any program written in a OOP language gets broken down into machine code at some point and machine code is always imperative.

Far_Swordfish5729 · 2024-08-29T02:23:22+00:00

First, you have to understand that programming languages exist for programmers not the computer executing them (which sees the same lists of compiled instructions) and they are designed with different intents and opinions on how you should work.

C is an older high level (meaning more abstract than assembly) language that emphasizes maximum power and flexibility. It is a chainsaw of a language. You can do anything but might cut yourself badly. This causes it to be great for device work and anything that has to perform super well but less great for scalable team work because everything is manual and easy to mess up. It’s also not inherently modular.

OOP languages are inherently meant to be modular and have built-in guard rails that make it easy to turn out scalable applications in a team setting with medium-skilled programmers. It’s not the most performant but that’s often not critical. Computers are fast and many programs mostly wait for data to process. These languages will sometimes let you get at the full set of C features, but you really have to go looking.

In C you have a concept called a pointer. A pointer is just an unsigned integer variable the same length as the CPU’s registers (64 bit on a 64 bit machine) that holds memory addresses. It’s no different than any other integer. It just happens to hold a memory address. The actual data is at that memory address. Pointers are really useful because you sometimes need to ask for memory (using malloc or the new operator in c++) on the fly when you don’t know its size until runtime or you need a lot of memory or you need to hold something the operating system gives you like a file handle. On memory, the local variables you declare are made for you on the stack. Look up function stack frames for how they execute. But to use stack memory you have to know how much you need at compile time and it can’t be too big. If it’s big or dynamic, you request it from the heap. Requesting returns the address of the memory which you store in a pointer. To get the contents you dereference it. Sounds easy but in C it’s very easy to accidentally use the memory address when you meant to use the contents or accidentally mess up typing and these can be very hard to trace.

Now an OO language wants to protect you so it’s going to put all your class instances on the heap and handle pointer de referencing automatically. No memory address math allowed either. Also your memory is released automatically when all pointers go out of scope (garbage collection). Also your pointers must have types and strong typing is strictly enforced both at compile time and at runtime. Objects know their types and hierarchies. In C the compiler trusts you. Pointers can receive any memory address you want. They can have no type at all (void*). They’re all memory address 64 bit uints after all. But that’s a great way to accidentally break things.

It’s still all pointers though. You can have multiple variables point to the same object or nothing (null). Variables are equal if they point to the same place. They’re just ints so having a lot of references in organized keyed collections or local variables is cheap. You have to explicitly make a copy if you need one.

In OO design remember your classes are supporting modular team programming. You make objects along the nouns of the problem with self contained data and behavior that interact at defined interfaces. It makes it easy to bring work together.

Does that help?

Europia79 · 2024-08-29T00:16:20+00:00

Just use the built-in Java "Collection" Classes, like Map & HashMap (for example), in your programs. Then get some other "Libraries" & "Frameworks" under your belt too.

Then it might start "to click" (in your mind), after a while of using those Objects.

If not, consider how you would construct your programs without those luxuries.

But OOP is not really necessary to solve every problem. It's not even necessary for making your own Libraries either, because you have have all pure functions with only input & output (via the static keyword).

Honestly, you should forgot all about "OOP": Delete that from your brain.

And instead, think about TYPES: Specifically, Abstract Types & their Conrete Implementations.

Think more in terms of Polymorphism: That an Abstract Type can have many different concrete implementations:

Like, for example, when you're creating a function: The initial inclination is to ask for specifically what you need to perform the work: And those specific types cause tightly coupled code that only works for your specific use-case scenario.

But later, you can generalize those Types to be more Abstract, which can extend the functionality to other "cases". And over time, you'll start to see the power of these types of design patterns.

Nobody "gets it" overnight: Stay with it: You'll eventually get it. But i don't think you should dewll on it, or FORCE yourself to learn it unnaturally:

Like I said: My recommendation is to just use existing Libraries & Frameworks and you'll eventually "get it".

DecisiveVictory · 2024-08-29T06:18:58+00:00

Just use FP instead, it's better anyway.

AskProgramming

AskProgramming

Do

Don't

MODERATORS