|
The idea is that the customer object should know all the things to be
done with it. You would have a method Customer.dial() rather than
surfacing the phone number for some other object to do the dialing. This
reaches some level of impracticality. Phone number itself might be an
instance of a class that knows how to dial itself. Then Customer.dial()
would just call PhoneNumber.dial() but it would be transparent to the
calling object.
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of James Perkins
Sent: Tuesday, February 03, 2009 5:37 PM
To: Java Programming on and around the iSeries / AS400
Subject: Re: Java Accessors Are They Evil?
Well, I am a procedural programmer, so that could by why I'm having
trouble grasping this ;-)
My basic class structure for a customer would look something like this.
A Customer class that represents various information about the customer,
id, address, etc.
A CustomerFactory (maybe bad terminology) an interface that would build
the customer.
A CustomerFactoryImpl that would implement the CustomerFactory interface
and build the customer based on a database file.
How would I access information in the Customer class with no accessors?
If I need to know the customers phone number, wouldn't I have to have an
accessor?
And please let me know if I'm completing insane and making a mockery of
the Java language. It's the only way I'll learn ;-)
James R. Perkins
On Tue, Feb 3, 2009 at 15:04, Dan Kimmel <dkimmel@xxxxxxxxxxxxxxx>
wrote:
Yes. Accessors are Evil.
The author (this was written in 2003) points out correctly that
accessors are PROCEDURAL artifacts. If you design your classes and
methods well, there's no need to access the instance values of an
object other than through the methods of the class (class methods and
instance methods). The author also points out that database interface
IS PROCEDURAL; that database access requires procedural code. Still, I
try to design my database interface such that it implements objectinfinitely.
persistence. The class can instantiate from a database and serialize
an instance to the database but it doesn't have to. The object could
stand alone without the database if I could keep memory refreshed
Methods on the object (eg, Employee.increasePay(int bumpUp)) update
the database and maintain values in the object. I might have a class
method such as Employee.instantiateFromDatabase(String empno) that
will do all the fetch necessary.
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of James Perkins
Sent: Tuesday, February 03, 2009 3:06 PM
To: Java Programming on and around the iSeries / AS400
Subject: Java Accessors Are They Evil?
Hello All,
I realize this article is kind of old, but I found it interesting none
the less.
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
I just can't figure out how you can get around getters and setters. I
understand it makes more sense to build a method to calculate a
discount or something like that, but what I don't understand is how
you create an object based on data from a database?
Maybe I'm over thinking this or taking what the author is writing too
literally, but I'm curious to see what some of you more experienced
Java developers think.
James R. Perkins
--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list To post a message email:
JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list
options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives athttp://archive.midrange.com/java400-l.
--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list To post a message email:
JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list
options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at--
http://archive.midrange.com/java400-l.
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/java400-l.
--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.
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.