Hi all I looked thru FAQ but I found nothing on class member variables and local variables. So here goes...
I have a program where I've defined a large number of variables to the class declaration, one of my java tutorial pdf's referred to these as "member" variables
They are all declared as static, meaning there's only one instance of the variable. HOWEVER in my program which I have divided into the "main" method
which calls other methods, I reference these variables. Now if I enclose a set of "member" variables (using the exact name, as in the class declaration) within
braces, within a method, these variables are actually local, and have no "association" or reference to the class member variables.
below is a snippet from my program
I fixed your code tags...when you click the button, you get both tags together - your code needs to be pasted between the ']' and the '['.
It really all depends on where you declare the variable - i.e. where you put the '<variable type> <variable name>', like "String fred".
in your sample code's main method, you are NOT using a local variable, or a member variable. You are using a static one.
As you correctly point out, there is only one "message_data" variable, no matter how many instances (if any) of your LU62XnsCvr class you create. From what I see, you never make any in this example.
IF, in your main method, you had DECLARED a StringBuffer named message_data, then it would be local. But since you never say 'StringBuffer message_data' in your main, you don't get a new one.
In your case statements (starting around line 147), you do make some new declarations - "FileOutputStream MesgOut", "FileChannel MesgChnl". Since those are declared inside a method, they ARE local variables to that method. Even more so, since they are declared inside a set of curly braces, they actually fall out of scope once you leave those curly braces. It is possible (i'm not 100% sure here) they may even fall out of scope once you leave the case of the switch. I don't know if that defines a scope, i'd have to test it.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Thanks very much Fred for your thoughts... I'm beginning to understand java a bit more ... and why I'm getting the compiler error messages.
I really should've written this application in C. java is designed for code that will be shared and utilized by the web community at large.
However, I'm too far down the path now, so I'll persevere. Thanks for the tip on the code tags.
Your code does look a lot like an old-style C program, with a whole list static member variables being used like you would use global variables in C (and using too many global variables is also a bad practice in C). Try minimizing the scope of variables as much as possible - prefer local variables inside methods above member variables. If you have many variables that have a broad scope, then it becomes hard to get an overview of how the code works, because any of those variables could be changed or read anywhere in the program. If you re-use such a variable for different purposes in different parts of the program it becomes even harder to understand the program and it also becomes very error-prone; you could inadvertently be overwriting a value in one part of the program that another part of the program needs later on.
A local variable is a variable declared inside a method. A variable declared at class level is a member variable.
For example, there is no reason why variables Parm0_Path and Parm1_luname are declared as static member variables. These could just be declared as local variables inside the main() method.
Also, many of the variables in lines 4 - 14 aren't used at all in the rest of the program, or are only written to (for example Runtime_Path and APPC_Partner in lines 121, 122) and never read. Why do you have these variables if they're not used for anything?
Look at the method FileControl(), lines 143 - 301. It's a very big method that contains a big switch statement that does a lot of different things, depending on the value of the variable pgm_status (which is not declared anywhere in your code). This is not how you would normally write a method.
Instead of writing one big method which does everything, write small methods that each have a single purpose. The code of each of the cases in the switch statement belongs in a separate method, with a name that makes clear what the purpose of the method is. Your code is far from an object-oriented, well-structured Java program.
Note that you don't need to explicitly extend Object - all Java classes implicitly extend Object. So, you can just leave out the "extends Object" in line 1.
StringBuffer has been superseded by StringBuilder. It's better to use StringBuilder instead of StringBuffer. (The difference is that StringBuilder doesn't have the unnecessary synchronization of StringBuffer, so it's not thread safe, but more efficient - you'll almost never use a StringBuilder object from multiple threads at the same time).
Hi Jesper Thank you for your observations...
You're right I shoud've wriiten this program in C. The purpose of the program is rather singular and specialized, and it's using an older
SNA type of communications, namely APPC/LU6.2 So it won't be shared or put to any use outside of it's current environment.
However I was asked to write it in Java... Java certainly has it's place and performs well for the purposes it's intended.
I don't have a problem with "Global" variables, in fact I'm rather fond of them, In my 31 years of programming I've used global variables with
great success. It's just another way to "look at the world". Being an old assembler programmer (both "mainframe'" and x86) It all boils down to
the machine code. A program any program is just a dynamic switching system, that manipulates and transfers "data".
Java, C/C++/C#, COBOL, PHP, Perl, LISP, ALGOL,FORTRAN, PL/I etc ... that's all in our heads not the machine's...
I understand where you're coming from, in the world of mainframe programming and assembly language the model that you have in your head while programming is quite different than when you are using a higher-level, object-oriented programming language. This style of programming works for you for this small program, but it will not scale to larger projects. If you'd use this style to build a large system then it would become much harder to maintain then when it would be designed and written in an object-oriented way.
In object-oriented programming there are a number of basic principles such as data abstraction and encapsulation that are specifically about making data as local as possible and minimizing the dependencies between the different modules of the program. These things are important if you want to build a larger piece of software that's maintainable. Global variables is the opposite of data abstraction and encapsulation.
Ofcourse when you finally run the program, it's all converted to native machine code, so indeed Java, C++, and all of those higher-level languages are all in our head. But all of those higher-level languages are there to make it easier for us humans to write large pieces of software.
Hi Jesper, thanks for your reply ... Java works well for the purposes it was intended ... basically the world-wide-web.
However I beg to differ regarding ease of maintenance in very large systems.
I have worked on some very large systems over the years, yes some of them have been difficult to maintain, others (well designed ones) have not.
If you carefully consider what a "database" is , you'll realize it's external global data. Now for all the advances that have been made in information technology, it still comes down to input-process-output. That's all any of these systems do.
The REAL key to ease of maintenance, and system longevity, is to remove data-presention and data-acess logic from the business-logic.
It really won't matter what language you write in if you keep that deisgn principle firmly in mind.
Business Logic is rule-driven based on a given business model. Accounting Programs are a good example...
All accounting systems whether single-entry or double-entry adhere to some basic principles and tenets of law.
Indeed one can externalize these rulesets, and comeup with an accounting system that's extremely flexible.
The rulesets themselves can be placed in a database.
XML which is a major key in data transport across disparate systems is actually a sub-set of a larger specification SGML, developed by IBM in the late 80's
This is another example of externalization of "global" data.
The real issue is to carefully analyze the task at hand, and select the right set of "tools" to get the job done...
Yes, I'm enjoying learning Java... may I humbly suggest you learn some assembler (if you don't already know it)
I learned programming in BASIC and assembly language when I was a kid on my Commodore 64 (with its 8-bit MOS 6510 processor), and later I programmed in C and assembly language on the Amiga 2000 that we had (with its 16/32-bit Motorola 68000 processor). The instruction set and organization of the 68000 was much cleaner than the messy Intel x86. But that was long ago, and I haven't written anything really big in assembly language.
I'm glad I learned those things, because it gave me a very good understanding of how computers work at a low level. I notice sometimes that there are programmers who have no idea how the computer exactly runs the programs that they're writing...
I think it's a bit misleading to say that Java was intended "for the world wide web". After all, it was originally intended for embedded systems! What it's become most successful at is enterprise scale systems (including, but not limited to, the world wide web", though there are plenty of applications showing it's good at other things as well.
But I think the important thing is that anyone will produce better software in any language following the paradigm that it was designed for (even if it can be used otherwise). Java is an object-oriented language, and you'll get the most out of it writing OO style code. If I was writing in C I'd get another job! use a structured approach. Other languages work best in different ways.