users
[Top] [All Lists]

RE: [cinjug-users] Question on last Monday's meeting

To: "Mark Windholtz" <windholtz@xxxxxxxxx>, <users@xxxxxxxxxx>
Subject: RE: [cinjug-users] Question on last Monday's meeting
From: "Mitchell, John" <jlmitchell@xxxxxxxx>
Date: Fri, 25 Feb 2005 10:20:38 -0500
Delivered-to: mailing list users@cinjug.org
Mailing-list: contact users-help@cinjug.org; run by ezmlm
Thread-index: AcUak7Wt8nzbkORESaOC1NAAJFWv3wAucX6A
Thread-topic: [cinjug-users] Question on last Monday's meeting
Mark,
 
I wasn't there when you talked about eliminating the use of
un-encapsulated, public constants.  Do you mean eliminate storing all of
the global (whether needed globally or not) constants in an interface
which all the classes inherit?  If a constant is needed by more than one
class, what is the alternative?  Feel free to refer me to an article or
something.

Thanks,

John

-----Original Message-----
From: Mark Windholtz [mailto:windholtz@xxxxxxxxx] 
Sent: Thursday, February 24, 2005 12:09 PM
To: users@xxxxxxxxxx
Subject: Re: [cinjug-users] Question on last Monday's meeting


Good question !

On Thu, 24 Feb 2005 10:17:28 -0500, steve.gutter@xxxxxxxxxx
<steve.gutter@xxxxxxxxxx> wrote:
>
> When the user (the one who is paying the bills) starts the project off
with
> 'we know what data is available,
> and we've mocked up what we want the pages to look like and how they
should flow,
> what we need is for someone to get it on the Web'
>
> ...
>  you'll never get out of the Data and Processing scenerio.
>
> How do you typically address these?
>

Your absolutly right.
That's why I say the the Data Processing attitude is deeply dug into
the larger culture.
The OO or DP decision is usually made before anyone knows that they
are actually making a decision.

However, you can at least put together a Simple Domain Model and
build with that.

The requirements above do push you into talking about data and
transformations, where you implemented is still (maybe) under control
of the  programmer/designer.

It's best of course if you can refocus the requirements discussion
away from data fileds and transformations
and onto business problems and behavior.

That is often quite tricky given that most IT people and most business
people deep in their sub-conscious can only think about programs in
terms of non-OO, data processing concepts.

That's one reason I also talked about small improvments we can make
like eliminating the use of un-encapsulated, public constants.

It's a small thing.
But it can move us all to focusing more on Behavior and Nameing.

With any change, I encourge Baby Steps in the OO direction.

--
Regards,
-Mark

---------
You may unsubscribe from this mailing list
by sending a blank email addressed to:
users-unsubscribe@xxxxxxxxxx

--
Find additional help by sending a blank email
addressed to:
users-help@xxxxxxxxxx



**********************************************************************
The content of this e-mail message and any attachments are confidential and may 
be
legally privileged, intended solely for the addressee.  If you are not the 
intended
recipient, be advised that any use, dissemination, distribution, or copying of 
this
e-mail is strictly prohibited.  If you receive this message in error, please 
notify
the sender immediately by reply email and destroy the message and its 
attachments.
**********************************************************************




<Prev in Thread] Current Thread [Next in Thread>