• Post Reply Bookmark Topic Watch Topic
  • New Topic

Dedicated newb struggling to call a method  RSS feed

 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Although I understand how to write a basic Java GUI, I seem to have forgotten the basics of passing variables from one class to another. I have searched and read about using getters and setters, but I'm puzzled as to how I would do it, in the context below.

My issue concerns 3 classes, I am just trying to call my method which updates a MYSQL database.

The stack trace states "cannot find symbol", and concerns this specific piece of code in my "Frontscreen" class.

updateDatabase callDatabaseUpdate = new updateDatabase(firstName , surname);
                               callDatabaseUpdate.viewTable(firstName,surname);

Both "firstname" and "surname" cannot be found.

My three classes are below.
---------------------------------------------------------------------------------


---------------------------------


---------------------------------------------------------------------


------------------------------------------------

I'd really appreciate some help with this, I am utterly convinced I need to use getters and setters, and I have read a lot about encapsulation, but I'm stumped!



 
Darren Estcourt
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Whoops, I forgot that I changed my method name, where the problem is concerned.

It is not "viewtable", it is infact "updateDatabase"

I'm sure someone noticed before I did
 
Ranch Hand
Posts: 434
7
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I give you some hint
https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
and
static keyword
https://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html
 
Darren Estcourt
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My variables are already public ?

I would understand, if I declared them private, but they aren't!
 
Ranch Foreman
Posts: 3068
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you're talking about lines 128/129 in FrontScreen, then where are firstname and lastname declared in that main() method?
 
Darren Estcourt
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
They aren't declared in my main method, they are declared in my ManagerName class.

I don't understand why I can pass both names to my updateMYSQL class, but not main.

From what I have read, I believe I need to use getters and setters, but I am not 100% sure how to implement this, and more specifcally, WHERE to implement them.

Thanks for any feedback, I have been going round in circles with this.

 
Dave Tolls
Ranch Foreman
Posts: 3068
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



The variables used on the problematic lines (firstName and surname) are not in scope in the main() method.
You have getters on ManagerName that will return those values from your test and test2 instances.

In fact it looks like you should be using the String variables declared just prior to those lines (forename and lastname).
 
Dave Tolls
Ranch Foreman
Posts: 3068
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, looking again at main() and not just for the compilation issues, I don't think this is going to do what you want.
Your invokeLater should cover all the construction of the display.
Those calls to pack() and visible() shouldn't be outside that...they could well end up called before FrontScreen has done anything.

What is it you are trying to do?
 
Darren Estcourt
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am trying to ensure that when the user enters their name, it is written to my MYSQL database (which I've done in my updateMYSQL method) and call that method, to ensure the name(s) is written to the database after the user has input the name(s).

Ideally, I then would use something like a JOptionPane to be invoked when the name(s) have been written to the database.

Really grateful for any help / suggestions.

 
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are many things wrong here, not the least of which is the design and organization. What has been discussed so far are nuts and bolts but Dave has only alluded to the larger problem, which is that your design is like a car that has its engine sitting on top of the hood and a steering wheel that controls the front right wheel and back left wheel only.

Database operations are backend operations and therefore should be separate and far away from the GUI, which is the user's view into the application. That's like how a car engine is kept under the hood and out of sight. However, your database class, updateMYSQL, has code that pertains to GUI and user input/display (lines 33 and 34). BTW, the name updateMYSQL is not a good name for any kind of class because it's a verb phrase, something that connotes an action. Class names should be nouns or noun phrases. By convention, they should also be capitalized. Class names should also avoid revealing implementation details about themselves, unless the class implements a generically-named interface and adding an implementation detail like "MySQL" to the class name would help differentiate it from other implementations of the same interface.  For example, if you have a ManagerDao interface (DAO stands for Data Access Object) that defines the persistence operations you can perform related to Manager objects, you can name the MySQL implementation of that interface as MySQLManagerDao to differentiate it from say a InMemoryManagerDao or XMLManagerDao implementation.

This brings us to your ManagerName class. A name seldom warrants creating a full-blown object just to represent it unless there are compelling reasons to do so. Given that the class you have only encapsulates a first name and a surname with very little behavior associated with them, I'd say that this class has little reason to exist. Looking around your code some more, however, we see that your data access class appears to want to associate a name to a team. That makes it a little bit more interesting but I don't know if it's enough to warrant a full-blown object yet. It's difficult to tell from what you have so far.

At any rate, it seems you are a little confused as to what this class that you've named ManagerName is supposed to represent. That is evident in this code:

This is like taking a piece of paper, handing it to the user and asking him to write down his first and last name. Then you take another piece of paper and ask the user to do the same thing. Then you go to your ledger (your database) and write down the first name from the first piece of paper along with the last name from the second piece of paper. That doesn't make any sense at all but that's essentially what that code is doing.  What's more, you're not even using the names consistently. On line 127, the variable name you use is lastname. Yet, on lines 128 and 129, you are attempting to pass a variable named surname to the data access object.

There are a few more things that are not right with the data access object design but I won't go into them now. I think the problems I've pointed out so far are enough to carry on this discussion for a while.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here are some guidelines you might want to consider as you try to find a better way to organize your program:

1. Keep different concerns separated. Use relatively independent classes to represent them. User input/display is one concern. Logical entities and their relationships are part of the problem domain, which is another concern. Persistence (saving/retrieving data) is another concern.

2. Classes don't always have to reflect real-world objects. They can be abstract ideas. What's important is to keep information and the behavior(s) that depends on that information together. That's how you define good, meaningful classes.

Reading up on Model-View-Controller and multitier architecture will also help you understand some of these things better. In your case, you can just keep your layering simple: Presentation layer (GUI), Logic/Flow layer (Model/Controller), and Database layer (Persistence).
 
Darren Estcourt
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the feedback, I am a self-taught newb, and whilst I fully respect these issues and will learn from them, my basic question is this : How would I call my updateMYSQL method from the main method, when the user has entered their name(s) and the data is written to the database.

I was simply trying to either use a JOptionPane or even a CLI message to confirm the data has been written to the database.


 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You'd use the correct names. Right now you're not. Look at the names you're using very carefully. The names need to be exact. Java can't figure out that when you use the name forename on one line of code and then refer to it as firstname in another line of code that you actually meant the same thing. Same thing with lastname and surname.  You have to use the same names that are defined in the program, not the synonyms you have floating around in your head.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Darren Estcourt wrote:
I was simply trying to either use a JOptionPane or even a CLI message to confirm the data has been written to the database.

Not a good reason. If anything went wrong with the database operation, you'd get an exception. The usual practice is to let that exception bubble back up through the layers until you get back to the presentation layer. That's where you display something to the user, not in your database layer.  Another option is to use logging and add a log message when the database operation fails or succeeds. Then you'd just look at the logs to see if your call succeeded or not.
 
Darren Estcourt
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just thought I was making a local copy of the name(s). but it makes sense for the variable names to be the same.

However........I now get an incompatible types error.

Clearly I have defined the variables as Strings, and yet the compiler says that the datatype is "ManagerName".

I can't just replace "String" with "ManagerName",

Please could you provide an example of what I should do?

It's a learning opportunity more than anything.

 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's an example. This is just off the top of my head though and based largely on what I wrote earlier about layering.

This code just gives the general idea of the flow.
 
Darren Estcourt
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My immediate thought looking at that, is using setters and getters i.e. encapsulation.

Thanks for that, It's given me a lot to think about.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Darren Estcourt wrote:My immediate thought looking at that, is using setters and getters i.e. encapsulation.

Yes, I think you're on the right track. Another guideline related to that is to keep your code high-level and abstract as much as possible. Resist the urge to immediately jump down into the details. When you think "parts of a car" you should first think at the level of "body, engine, suspension, fuel system" not "engine block bolt #1, retaining pin #8, lock nut, and volume control button."  The latter is essentially what your program looks like when I read it, you've buried yourself in the complexity of the details without having a clear idea of what your big picture is.
 
Darren Estcourt
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Prior to learning how to write basic GUI's, I was just going CLI stuff and agree that abstraction and interfaces offer a good "framework" or "model" which can be implemented etc.

However, this is not intended to be a massive program, it's more about learning than anything else.

My problem, is that I pursue random interests in programming, e.g. I am far more familiar with mysql than Java, so I decided to create a simple database and work out how to connect via jdbc and stuff.

It seems I forgot all about encapsulation, because I pursued mysql, and gui's, just to name a couple of digressions.

Thanks for all your help though
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Darren Estcourt wrote:However, this is not intended to be a massive program, it's more about learning than anything else.

The principle of separation of concerns can be applied at any scale. Your program doesn't have to be massive to benefit from following the principle.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's another example of how principles can be applied "in the small."  I previously wrote about how your updateMYSQL class name is inappropriate in that it reveals MySQL as an implementation detail. The example I gave was based on the assumption that I had the following defined:
Listing 1 - Declaration with interface

In this case, including "MySQL" in the implementation class name is intended to help differentiate it from other implementations of the same interface. If you want to keep the design simpler and not start with an interface right away, you'd write this instead:
Listing 2 - Simpler declaration, just one implementation

This more straightforward design without the interface implies that the current plan is to only have this one implementation that can handle Manager persistence concerns. Notice that I have removed the reference to MySQL in the name now. This goes back to the principle of not revealing implementation details unless there's a compelling reason to do so. Without a good reason, you want to follow the principle of abstraction and reveal only the intent or purpose, not implementation. In either case, the client code would be programmed like this:
Listing 3 - Sample client code

The choice of the name keeps us in line with the principle of "Prefer to program to abstractions, not implementations." This is the same principle/guideline behind writing this kind of code:
Listing 4. Program to abstractions, not implementations

Two differences to note between lines 2 and 5 (Listing 4). On line 2, we prefer to declare the interface type, List, rather than the implementation type, ArrayList. Also, the variable name reflects what the strings represent (names), not their implementation.

Let's assume you start out with the simpler design, with ManagerDao as a class. Notice that on line 1 & 4 (Listing 3), the declaration is the same whether ManagerDao is an interface or a class.  Later on, you may find that an implementation that works directly with a real database is difficult and slow to test. An in-memory implementation would be easier to work with while you're still developing and hashing out the details of your design. So you switch to the design where ManagerDao is an interface. In making that switch, you'd only have to change the right side of the assignment statement:

If you had programmed to the implementation type, you would have had to change both sides. That may seem trivial in this example but in real-life code, the ripple effect that such a change causes can be much worse and more widespread if you program to implementations rather than abstractions.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!