Object Jams in Java

I am working on an exercise to understand Java, and basically I need to combine the functionality of two classes in one application.

I am stuck on one area, though - binding objects to classes.

What I did was set up gui in one class (test1), and this has a text box, i.e.

chatLine = new JTextField(); 

in another class (test2), I planned to leave all the functionality there and refer to the various gui elements installed in test1 - like this test1.chatLine

I understand this link level, I checked this by setting a test method in the test2 class

 public static void testpass() { test1.testfield.setText("hello"); } 

I am trying to understand how to implement more complex functions in the test2 class, although, in particular, this existing code;

 test1.chatLine.addActionListener(new ActionAdapter() { public void actionPerformed(ActionEvent e) { String s = Game.chatLine.getText(); if (!s.equals("")) { appendToChatBox("OUTGOING: " + s + "\n"); Game.chatLine.selectAll(); // Send the string sendString(s); } } }); 

This is the bit I'm stuck on if I can do it - since it has not been compiled, I can add actionadapter material to the gui element that was sitting in test1, but to do it from test2 - I wonder if I'm trying to do something impossible .

Hope this makes sense, I'm pretty confused about this - I'm trying to figure out how the scope and links work.

Ideally, what I'm trying to achieve is one class that has all the basic elements, gui, etc., and then all the related functions in another class and are aimed at the first-class gui elements with the results, etc.

Any thoughts are greatly appreciated.

+4
source share
3 answers

If you can access chatLine in the first place, you can call its (public) methods, including addActionListener . To access chatLine directly, you need to make it public , and if you want to make it specific to a class (unlike another chatLine for each instance of the class), it must be static .

Please note, however, that publishing variables is often not recommended. An important reason for having classes and objects is primarily encapsulation. You can consider hiding the implementation inside the classes, making it private and providing only public methods of a higher level to access what is needed, for example. do not expose the "raw" JTextField , but rather provide the functionality that you use to provide it.

+2
source

I do not understand if chatLine is a local variable, an instance variable or a static variable. Any of these things could be the source of your compilation error that you did not specify - what error?

If it is an instance or a static variable, it can be made visible from anywhere, making it publicly available. This does not mean a good idea.

At the very least, it should be closed and open using the getChatLine () method.

Even then, the question arises as to whether this project is correct, but at least you will do it correctly at the compiler level and the basic level of data encapsulation.

+1
source

In general, everything in Java is referenced, but primitive types.

The so-called object visibility is another matter:

  • public visible members visible to all
  • “Package-friendly” members (those who do not have the area explicitly mentioned) are visible to all offenders belonging to the same package
  • protected members with restricted access "Package friendly" and inheritance of class objects visible to all
  • Finally, private members are visible only to the object itself [Objects from the same class can view each other (as far as I remember)]

Now

  • an internal static class can access it including the static class.
  • A "normal" inner class (without a static modifier) ​​can access its encompassing class of static members and an instance of the member environment object - this is also an anonymous inner class.

Finally, any chain of methods / fields, as indicated below, is valid (but ugly) if no part of the chain refers to zero:

 myObj.getThatObject().somePublicField.doSomthing().activate().someOtherPublicField 

One recommendation, although not to declare participants as public ...

+1
source

Source: https://habr.com/ru/post/1305653/


All Articles