|
Hi Shane, > is it common, then, to have a crapload of class variables?... The basis of object oriented programming is to create appropriate models of the problem domain, resulting in something called an Abstract Data Type. An ADT has both state and behavior. In Java, this is a class, which is more or less a blueprint for creating objects, which are particular instances of the class, each with their own data. State data that can't be easily or efficiently calculated on the fly should be kept as instance variables. Whether of not this entails a "crapload" is entirely dependent on the needs of the ADT. Even with instance variables, for reasons to do with encapsulation, you probably want to have methods to control access and modification of data by external objects. True method variables, as Chris mentioned, do not exist outside the method. Using all statics is a practice that limits your code and usually ends up biting you later on. This does not necessarily relate to you, but I often see it in what is essentially RPG ( C, COBOL, pick your non-OOPS language ) written in Java syntax. The same thing happened in C++, where programmers called themselves C++ programmers because they had a C++ compiler. Like most things, that's not necessarily bad, so long as the programmer understands what she is doing. Most of the time, however, it's a result of "gotta write the code", and the major benefits of OO and the bang for the buck are never seen. If you want to investigate further, there are plenty of books and articles about OO concepts. Here's a brief online introduction: "Object-Oriented Programming Concepts" http://java.sun.com/docs/books/tutorial/java/concepts/index.html Joe Sam Joe Sam Shirah - http://www.conceptgo.com conceptGO - Consulting/Development/Outsourcing Java Filter Forum: http://www.ibm.com/developerworks/java/ Just the JDBC FAQs: http://www.jguru.com/faq/JDBC Going International? http://www.jguru.com/faq/I18N Que Java400? http://www.jguru.com/faq/Java400 ----- Original Message ----- From: <Shane_Cessna@xxxxxxx> To: "Java Programming on and around the iSeries / AS400" <java400-l@xxxxxxxxxxxx> Sent: Monday, June 13, 2005 10:02 AM Subject: Re: "new to Java" question... > Mark, > > Thanks for the response...I just was curious if it could be done...is it > common, then, to have a crapload of class variables?... > > Shane Cessna > iSeries Programmer > iSeries WAS Administrator > North American Lighting, Inc. > (618) 662-4483 x2776 > shane_cessna@xxxxxxx > > > > MWalter@xxxxxxxxxxxxxxx > Sent by: java400-l-bounces@xxxxxxxxxxxx > 06/13/2005 08:57 AM > Please respond to > Java Programming on and around the iSeries / AS400 > <java400-l@xxxxxxxxxxxx> > > > To > Java Programming on and around the iSeries / AS400 > <java400-l@xxxxxxxxxxxx> > cc > > Subject > Re: "new to Java" question... > > > > > > > Isn't that the idea behind encapsulation? So method variables cannot be > accessed. Make them class variables. > > Thanks, > > Mark > > Mark D. Walter > Senior Programmer/Analyst > CCX, Inc. > mwalter@xxxxxxxxxx > http://www.ccxinc.com > > > > Shane_Cessna@nal. > com > Sent by: To > > java400-l-bounces JAVA400-L@xxxxxxxxxxxx > @midrange.com cc > > > Subject > > 06/13/2005 09:52 "new to Java" question... > AM > > > Please respond to > Java Programming > on and around the > iSeries / AS400 > <java400-l@midran > ge.com> > > > > > > > Is there an easier way to access method variables in another method other > than passing them on the call? here's an example: > > public static void main(String args[]) { > DB2400 nal820 = new DB2400("nal820"); > getData(nal820); > nal820.disconnect(); > } > > public static void getData(DB2400 nal820) { > //process data > } > > could I do something in the getData method to access my "nal820" variable > without passing it? I'm sure it's something really easy and basic, but > like the subject says, it's a "new to Java" type of question...Thanks... > > Shane Cessna > iSeries Programmer > iSeries WAS Administrator > North American Lighting, Inc. > (618) 662-4483 x2776 > shane_cessna@xxxxxxx > --
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.