What is hidden behind the concept of class in OOP?

Question

Java

Hello. Tell me, please, do I understand the concept of a class in OOP correctly?
I understood it this way: We cannot work directly with the class, so we work with instances of the class (that is, with its objects), which in turn have properties, events and methods. Each object has its own interface, which in turn determines what requests we can send to this object.
But we also cannot work directly with the object, so we give our object a name (that is, we make a link to it indicating that the name we created is the same object). We cannot change the object directly, so we create a new instance of this object through the new operator. With which we can already perform some action.

Light lt = new Light()
lt on();

From what I understand from this code. We have an OnClickListener object with which we cannot work directly. Therefore, we give this object a name (that is, we make a reference to the object), in our case it is btnOK. In order for us to work with btnOK, we must create an instance of this object, which in turn we can change (that is, which can respond to our requests).
The OnClickListener object has an onClick event that fires when the button is clicked. The tvOut object has a setText event that displays the text we need.

OnClickListener btnOK = new OnClickListener() {
       @Override
       public void onClick(View v) {
         // Меняем текст в TextView (tvOut)
         tvOut.setText("Нажата кнопка ОК");
       }
     };

This is how I understand it, but OnClickListener is not an object, but a method. And here it is called an event

<Button
    android:id="@+id/butHello"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_alignParentLeft="true"
    android:layout_alignParentTop="true"
    android:onClick="butHello_Click"
    android:text="Поздороваться" />

And here is the method.

public void butHello_Click(View v){
    TextView tvHello = (TextView)findViewById(R.id.textView1);
    tvHello.setText("Hello!!!");
}

What is the difference here?
Please do not swear, but help me figure out what my mistake is. I need to understand this, preferably with examples. Thanks for the help.

Answer 1

It's not clear what you mean by "directly work with an object"... A
class allows you to put together (encapsulate) properties (data) and methods (code). In the class definition, you describe what data types (sometimes default values) and what specific code. Further, by creating (instantsirovanie) objects of this class, you allow them to have different data - this is how they differ. But their behavior is the same. Unless of course in the methods you do not branch the behavior depending on the properties of the object. But that would be a bad decision. It's better to create new classes and inherit them from the original one. And objects to instantiate already from them.
You can work directly with a class if its methods and properties are static. In this case, the class is usually used as a library of functions and constants. Moreover, the class can combine both static and ordinary fields.
I may be wrong about the specific code, but it seems to be like this:
OnClickListener is a class. You create an object of this class. The onClick method is bound somewhere else to the button's click event. In your code, you are simply overriding its behavior. In particular, you call the method of the tvOut object.
PS It is possible that where you read, the methods attached to events (of the user interface and others) are called events.

Answer 2

you are confused about the basic abstractions - that is your problem. and even if you explain what exactly you made a mistake in this matter, tomorrow you will come running with a new one, and so on ad infinitum.
you need a book that is more about oops and less about buttons :)

Answer 3

your reasoning is utter rubbish.
To understand what an object is, you need to imagine, for example, wallpaper production: a stencil is a class, and one roll of wallpaper is already an object with its own properties such as size, color, paper composition, etc.
In programming, this abstraction can explain something a little, but is far from reality. All methods in an object reside in the class and remain unchanged. But the object itself is an allocated amount of memory, sufficient to contain all the fields of this object. Accordingly, for object methods there is one distinctive feature: the first parameter passed in them is a reference to the area where the object is located, although this variable is often not shown in the development environment. That is, it turns out that we use methods, passing them a reference to an object, use the necessary fields referring to the memory relative to the beginning of the object.
Another interesting feature is the class methods and fields (or in relation to Java - static). These elements are already distributed in the class in a single instance. Therefore, they are accessible from any object. But the difference between such methods and object methods is that the first variable always refers to the beginning of the class. This means that in such methods nothing is known what is happening in the objects. Yes, and calling object methods from them always requires the presence of the already created object itself. Some PLs do not do this. therefore, you can sometimes "cheat": if the method does not work with the fields of the object or references to other methods where work is carried out with the fields of the object, you can fictitiously call it by indicating that the object is 0 (an example of such a "glitch" is in C ++, in Delphi, in PHP [although it's not a language]).
Be careful with the word "interface". In PL, an interface is an extension of the functionality of classes, introducing common features into them. Classes can only be scaled by inheritance (we will not touch on encapsulation). That is, two classes cannot be united by common features if they are not "relatives". But here interfaces come to the rescue. If we imagine inheritance as a "vertical" extension, then with interfaces we achieve a "horizontal" extension.
Now about events. In order to organize some kind of event in PL, we need to know two things: the object that should respond and the method that should be called on this object. This means that the event is described by at least two fields. In Java, it is rather problematic to create such a complex structure every time. Therefore, listeners were invented for events - objects extended by some specific interface. The presence of such an interface in an object gives a guaranteed presence of the desired method, and we need to save only a reference to the desired object.

Answer 4

Your mistake is that you are confusing methods and events. You can read more about events on msdn .
In this case, butHello_Click is the method that is called when the button is pressed event occurs.

Answer 5

Yes, on the run. It should be understood that the objects themselves can generate their own events, which can have their own listeners (ie, methods of other objects that are called when events occur).
A very contrived example:
You make a text field into which text is entered. There is an object whose method is called every time the user interface generates an onChange event on this field. Your object parses the text field and if it matches some value, does something. Let's assume that this needs to be done by means of other objects in the system. You have an option - either in your object to call their methods. Or generate an event of type "onTextFieldSetTo" and then other objects can listen to this event and work independently.