Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.help > #1636 > unrolled thread

Validating form inputs?

Back to article view | Back to comp.lang.java.help

Contents

  Validating form inputs? Davej <galt_57@hotmail.com> - 2012-03-20 11:16 -0700
    Re: Validating form inputs? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-20 12:08 -0700
      Re: Validating form inputs? Lew <lewbloch@gmail.com> - 2012-03-20 12:50 -0700
        Re: Validating form inputs? markspace <-@.> - 2012-03-21 09:24 -0700
        Re: Validating form inputs? Davej <galt_57@hotmail.com> - 2012-03-21 12:02 -0700
          Re: Validating form inputs? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-21 12:59 -0700
          Re: Validating form inputs? Lew <lewbloch@gmail.com> - 2012-03-21 13:37 -0700
      Re: Validating form inputs? Davej <galt_57@hotmail.com> - 2012-03-20 12:56 -0700
        Re: Validating form inputs? Lew <lewbloch@gmail.com> - 2012-03-20 13:58 -0700
        Re: Validating form inputs? markspace <-@.> - 2012-03-21 09:30 -0700
    Re: Validating form inputs? Roedy Green <see_website@mindprod.com.invalid> - 2012-03-20 14:28 -0700
      Re: Validating form inputs? Gene Wirchenko <genew@ocis.net> - 2012-03-20 19:16 -0700
        Re: Validating form inputs? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-21 17:41 -0300
          Re: Validating form inputs? Gene Wirchenko <genew@ocis.net> - 2012-03-21 14:46 -0700
            Re: Validating form inputs? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-21 19:54 -0300
          Re: Validating form inputs? Roedy Green <see_website@mindprod.com.invalid> - 2012-03-22 10:34 -0700
        Re: Validating form inputs? Lew <lewbloch@gmail.com> - 2012-03-21 14:56 -0700
          Re: Validating form inputs? Gene Wirchenko <genew@ocis.net> - 2012-03-21 19:09 -0700
            Re: Validating form inputs? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-22 08:36 -0700
              Re: Validating form inputs? Gene Wirchenko <genew@ocis.net> - 2012-03-22 09:40 -0700

#1636 — Validating form inputs?

I have been thinking about the way I have been validating form inputs
in the servelet and wonder if I would be much better off using class
methods to verify these inputs?

Consider that I am almost always gathering the inputs to instantiate
one or more objects, but I gather and validate -- and then
instantiate. Maybe I should instantiate an empty object and then use
class methods to validate the inputs?

Thanks

[toc] | [next] | [standalone]

#1637

On 3/20/12 11:16 AM, Davej wrote:
> I have been thinking about the way I have been validating form inputs
> in the servelet and wonder if I would be much better off using class
> methods to verify these inputs?
>
> Consider that I am almost always gathering the inputs to instantiate
> one or more objects, but I gather and validate -- and then
> instantiate. Maybe I should instantiate an empty object and then use
> class methods to validate the inputs?
>
> Thanks
There are a few frameworks that do this in several phases actually. Its 
called binding and validating.

In the binding phase, values are parsed into appropriate data types, and 
stored in the model (Form object as it is sometimes called).  If the 
data can not be parsed, or the model rejects the value immediately, it 
is a binding error.

In the validation phase, the values are checked for correctness. This is 
often a secondary phase because some values are interdependent.

If, after validation, you want to have an immutable object, then you 
could treat your Form object more as a Builder object, and have it 
construct the Real object, which is fully populated and validated. 
Alternatively, you could use the Form object as a "Parameter" object for 
a different Builder class, to keep the concerns of the Form object more 
pure.

I suggest looking into different frameworks, rather than trying to 
roll-your-own. There are a lot of gotchas that can be avoided, and 
boilerplate code you can rid yourself of.  I've had moderate luck with 
Spring Binding.  If you have typical use-cases it works well.  If you 
have more complicated forms, for instance complex dynamic items, then 
there is some shoehorning needed to make it work correctly.

Hope this helps,
Daniel.

[toc] | [prev] | [next] | [standalone]

#1638

Daniel Pitts wrote:
> Davej wrote:
>> I have been thinking about the way I have been validating form inputs
>> in the servelet [sic] and wonder if I would be much better off using class
>> methods to verify these inputs?

What exactly do you mean by "class methods"? Do you mean 'static' member methods?

>> Consider that I am almost always gathering the inputs to instantiate
>> one or more objects, but I gather and validate -- and then
>> instantiate. Maybe I should instantiate an empty object and then use
>> class methods to validate the inputs?

Maybe.  It depends on what you mean by "class methods".

> There are a few frameworks that do this in several phases actually. Its 
> called binding and validating.
> 
> In the binding phase, values are parsed into appropriate data types, and 
> stored in the model (Form object as it is sometimes called).  If the 
> data can not be parsed, or the model rejects the value immediately, it 
> is a binding error.
> 
> In the validation phase, the values are checked for correctness. This is 
> often a secondary phase because some values are interdependent.
> 
> If, after validation, you want to have an immutable object, then you 
> could treat your Form object more as a Builder object, and have it 
> construct the Real object, which is fully populated and validated. 
> Alternatively, you could use the Form object as a "Parameter" object for 
> a different Builder class, to keep the concerns of the Form object more 
> pure.
> 
> I suggest looking into different frameworks, rather than trying to 
> roll-your-own. There are a lot of gotchas that can be avoided, and 
> boilerplate code you can rid yourself of.  I've had moderate luck with 
> Spring Binding.  If you have typical use-cases it works well.  If you 
> have more complicated forms, for instance complex dynamic items, then 
> there is some shoehorning needed to make it work correctly.

Rolling your own isn't actually that hard, but you won't get the breadth, depth or solidity of a framework with thousands of manhours invested in it already. Then again, you might not need all that.

There are plenty of better frameworks out there than Spring. There's JSF, regular old JSP with EL and JSTL, and Struts, to name three.

Your use of the term "class methods", OP, suggests that you need to study Java some more, and likely also servlets and presentation technologies some more. Look up the "Model 2" web-application paradigm. Then go with JSP/EL or JSF/Facelets.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#1644

On 3/20/2012 12:50 PM, Lew wrote:
> Daniel Pitts wrote:
>> Davej wrote:
>>> I have been thinking about the way I have been validating form
>>> inputs in the servelet [sic] and wonder if I would be much better
>>> off using class methods to verify these inputs?
>
> What exactly do you mean by "class methods"? Do you mean 'static'
> member methods?


Class methods:

<http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html>

;)

[toc] | [prev] | [next] | [standalone]

#1646

On Mar 20, 2:50 pm, Lew <lewbl...@gmail.com> wrote:
> Daniel Pitts wrote:
> > Davej wrote:
> >> I have been thinking about the way I have been validating form
> >> inputs in the servelet [sic] and wonder if I would be much
> >> better off using class methods to verify these inputs?
>
> What exactly do you mean by "class methods"? Do you mean 'static'
> member methods?
>
> >> Consider that I am almost always gathering the inputs to
> >> instantiate one or more objects, but I gather and validate
> >> -- and then instantiate. Maybe I should instantiate an empty
> >> object and then use class methods to validate the inputs?
>
> Maybe.  It depends on what you mean by "class methods".
>

Why? I think it could be done either way. If it was a static method is
would be made generic. If it was non-static it could be an alternate
set method...

public String ValidateAndSetQuiz1(String q1) //returns error message
{
  double score;

  try{
     score = Double.parseDouble(q1);
     if ( score < 0 || score > 100.0)
        return "Value out of allowed range";

  }catch (Exception e)
  {
     return "Value is non-numeric";
  }

  m_quiz1 = score; //accept and set instance variable m_quiz1
  return null; //signifies that submitted value was accepted
}

[toc] | [prev] | [next] | [standalone]

#1647

On 3/21/12 12:02 PM, Davej wrote:
> On Mar 20, 2:50 pm, Lew<lewbl...@gmail.com>  wrote:
>> Daniel Pitts wrote:
>>> Davej wrote:
>>>> I have been thinking about the way I have been validating form
>>>> inputs in the servelet [sic] and wonder if I would be much
>>>> better off using class methods to verify these inputs?
>>
>> What exactly do you mean by "class methods"? Do you mean 'static'
>> member methods?
>>
>>>> Consider that I am almost always gathering the inputs to
>>>> instantiate one or more objects, but I gather and validate
>>>> -- and then instantiate. Maybe I should instantiate an empty
>>>> object and then use class methods to validate the inputs?
>>
>> Maybe.  It depends on what you mean by "class methods".
>>
>
> Why? I think it could be done either way. If it was a static method is
> would be made generic. If it was non-static it could be an alternate
> set method...
>
> public String ValidateAndSetQuiz1(String q1) //returns error message
> {
>    double score;
>
>    try{
>       score = Double.parseDouble(q1);
>       if ( score<  0 || score>  100.0)
>          return "Value out of allowed range";
>
>    }catch (Exception e)
>    {
>       return "Value is non-numeric";
>    }
>
>    m_quiz1 = score; //accept and set instance variable m_quiz1
>    return null; //signifies that submitted value was accepted
> }
>

Augh, no.

The setter should throw an exception if the value isn't valid.  Also, a 
setter should take in a correctly typed parameter, not a string to be 
parsed.

[toc] | [prev] | [next] | [standalone]

#1649

Davej wrote:
> Lew wrote:
>> Daniel Pitts wrote:
>>> Davej wrote:
>>>> I have been thinking about the way I have been validating form
>>>> inputs in the servelet [sic] and wonder if I would be much
>>>> better off using class methods to verify these inputs?
>>
>> What exactly do you mean by "class methods"? Do you mean 'static'
>> member methods?
>>
>>>> Consider that I am almost always gathering the inputs to
>>>> instantiate one or more objects, but I gather and validate
>>>> -- and then instantiate. Maybe I should instantiate an empty
>>>> object and then use class methods to validate the inputs?
>>
>> Maybe.  It depends on what you mean by "class methods".
>>
> 
> Why? I think it could be done either way. If it was a static method is
> would be made generic. If it was non-static it could be an alternate
> set method...

You asked if you "should instantiate an empty object". That would not be needed if using static methods only. That's why I said "it depends on what you mean by 'class methods'".

> public String ValidateAndSetQuiz1(String q1) //returns error message

Please follow the Java naming conventions.

> {
>   double score;

You could narrow the scope of 'score' more if you wanted to.

>   try{
>      score = Double.parseDouble(q1);
>      if ( score < 0 || score > 100.0)
>         return "Value out of allowed range";
> 
>   }catch (Exception e)

What exception are you catching?

For most routines, catching just 'Exception' is an antipattern.

>   {
>      return "Value is non-numeric";

And as Daniel noted, this is not often the best way to handle an exception.

I would wonder if logging the exception is appropriate here, perhaps.

>   }
> 
>   m_quiz1 = score; //accept and set instance variable m_quiz1
>   return null; //signifies that submitted value was accepted
> }

It's more conventional to return a value than 'null' or a 'String' that are not in the value domain.

It's likely to be better engineering to separate setting and validation into different methods.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#1639

On Mar 20, 2:08 pm, Daniel Pitts
<newsgroup.nos...@virtualinfinity.net> wrote:
> On 3/20/12 11:16 AM, Davej wrote:
> > I have been thinking about the way I have been validating form inputs
> > in the servelet and wonder if I would be much better off using class
> > methods to verify these inputs?
>
> > Consider that I am almost always gathering the inputs to instantiate
> > one or more objects, but I gather and validate -- and then
> > instantiate. Maybe I should instantiate an empty object and then use
> > class methods to validate the inputs?
>
> > Thanks
>
> There are a few frameworks that do this in several phases actually. Its
> called binding and validating.
>
> In the binding phase, values are parsed into appropriate data types, and
> stored in the model (Form object as it is sometimes called).  If the
> data can not be parsed, or the model rejects the value immediately, it
> is a binding error.
>
> In the validation phase, the values are checked for correctness. This is
> often a secondary phase because some values are interdependent.
>
> If, after validation, you want to have an immutable object, then you
> could treat your Form object more as a Builder object, and have it
> construct the Real object, which is fully populated and validated.
> Alternatively, you could use the Form object as a "Parameter" object for
> a different Builder class, to keep the concerns of the Form object more
> pure.
>
> I suggest looking into different frameworks, rather than trying to
> roll-your-own. There are a lot of gotchas that can be avoided, and
> boilerplate code you can rid yourself of.  I've had moderate luck with
> Spring Binding.  If you have typical use-cases it works well.  If you
> have more complicated forms, for instance complex dynamic items, then
> there is some shoehorning needed to make it work correctly.
>
> Hope this helps,
> Daniel.

This brings up an issue I would be interested in hearing comments on.
In the curriculum I am pursuing we get an overview of Java and then an
overview of JSP and servelets and then finally in the 3rd semester we
get to frameworks such as Struts. Is this the normal progression? Does
this sequence encourage bad practices or lots of things that need to
be unlearned?

Thanks

[toc] | [prev] | [next] | [standalone]

#1641

Davej wrote:
> This brings up an issue I would be interested in hearing comments on.
> In the curriculum I am pursuing we get an overview of Java and then an
> overview of JSP and servelets [sic] and then finally in the 3rd semester we
> get to frameworks such as Struts. Is this the normal progression? Does

Do a survey of curricula to find out. 

I would be surprised if anyone here has that information at hand, unless it's amenable to a search such as 
http://lmgtfy.com/?q=normal+progression+to+teach+Java%2C+servlets+and+frameworks

(Unfortunately that particular search is not especially successful. You're on your own for crafting a better query.)

> this sequence encourage bad practices or lots of things that need to
> be unlearned?

On the contrary, it seems the best way to teach what you need to know so that you don't fall victim to Programming by Superstition.

Struts makes the best sense if you've implemented some Model 2 architectures yourself. (Look it up.) Then you can appreciate the advantages and limitations of the approach.

I've worked with people who could cite chapter and verse from the Struts Javadocs but had no sense of what it did. why it did it, or how to creatively make it do what they wanted. They could only follow dimly-understood lore from manuscripts illuminated by non-technical monks under candlelight. Had their curriculum followed your pattern, they might (!) have had deeper understanding.

Similarly. I learned JPA (Java Persistence API) best when I implemented my own ORM (Object-Relational Mapping) layer, in a couple of different ways using JDBC, then did it again in JPA.

You should understand the turtles all the way down.

-- 
Lew
From the famous saying, "It's turtles all the way down."

[toc] | [prev] | [next] | [standalone]

#1645

On 3/20/2012 12:56 PM, Davej wrote:
> This brings up an issue I would be interested in hearing comments on.
> In the curriculum I am pursuing we get an overview of Java and then an
> overview of JSP and servelets and then finally in the 3rd semester we
> get to frameworks such as Struts. Is this the normal progression? Does
> this sequence encourage bad practices or lots of things that need to
> be unlearned?


This is exactly the path I took when I taught myself JEE programming.

I tried to jump into JSPs and servlets right away.  This didn't work, 
and I had to back up and learn Java as a language more solidly first. 
Then the JSP/Servlet spec was much easier.

Then I added frameworks on top of that.  I think I'd prefer something 
more modern like JSF and JPA rather than just Struts.  However, I'm also 
told that there are quite a lot of legacy apps that use Struts so I'm 
sure there's work available there, and it's not a terrible choice by any 
means.

[toc] | [prev] | [next] | [standalone]

#1640

On Tue, 20 Mar 2012 11:16:36 -0700 (PDT), Davej <galt_57@hotmail.com>
wrote, quoted or indirectly quoted someone who said :

>I have been thinking about the way I have been validating form inputs
>in the servelet and wonder if I would be much better off using class
>methods to verify these inputs?
>
>Consider that I am almost always gathering the inputs to instantiate
>one or more objects, but I gather and validate -- and then
>instantiate. Maybe I should instantiate an empty object and then use
>class methods to validate the inputs?
>
>Thanks
It is rather rude to your user not to tell him he has made an error
until several seconds after he has keyed an entire page.  This is
almost as bad as 1960s batch processing. Even 1970s, 3270 terminals or
keypunches could tell you on a field by field or keystroke by
keystroke basis about many errors.

There are basically to ways to fix that.  Use an Applet on the client
or use Ajax. Both have serious drawbacks.

What is EXTREMELY rude is to erase some of his fields or even all of
them if he makes an error.

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It is almost impossible to keep things in synch manually. Instead: 
-Keep each fact in only one central database (not necessarily SQL),
and access it as needed. Since there is only one copy of each fact, 
there is nothing to get out of synch.
-Use some automated tool so that if you change a fact is one place,
it automatically updates the others.
-Write a sanity checker you run periodically to ensure all is consistent. 
This is the strategy compilers use.
-Document the procedures needed to keep all in synch if you change 
something and rigidly and mechanically follow them.

[toc] | [prev] | [next] | [standalone]

#1642

On Tue, 20 Mar 2012 14:28:09 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote:

>On Tue, 20 Mar 2012 11:16:36 -0700 (PDT), Davej <galt_57@hotmail.com>
>wrote, quoted or indirectly quoted someone who said :
>
>>I have been thinking about the way I have been validating form inputs
>>in the servelet and wonder if I would be much better off using class
>>methods to verify these inputs?
>>
>>Consider that I am almost always gathering the inputs to instantiate
>>one or more objects, but I gather and validate -- and then
>>instantiate. Maybe I should instantiate an empty object and then use
>>class methods to validate the inputs?

     Classes can be very useful.  They can also be a waste of time. If
the only reason that you use classes is because you get to use
classes, that is not a good idea.

     I recall one assignment during my degree where this got
demonstrated rather well.  We were to write code comparing various CPU
time allocation algorithms.  I figured out how to code it and wrote
it.  I wrote procedural code.  There was no need for classes except
for the one class Java requires.  One of my classmates went the OOPS
route.  It did not work out, and he had to restart just before the
assignment was due.  He did not get through the whole assignment.  My
classmate was a sharp person.

     Just because you have a tool is no reason to use it.  No, I am
not arguing not using it.

>>Thanks
>It is rather rude to your user not to tell him he has made an error
>until several seconds after he has keyed an entire page.  This is
>almost as bad as 1960s batch processing. Even 1970s, 3270 terminals or
>keypunches could tell you on a field by field or keystroke by
>keystroke basis about many errors.

     I am having a bit of a battle in comp.lang.javascript over my
writing a form handler that give error messages on a
control-by-control basis.

     While I understand the opposition point of view, they do not give
me much credence.  They are much too doctrinaire for my taste.
Supposedly, I am writing something very vulnerable to browser
versions, etc.  We shall see.  Interestingly enough, I can probably
remove that part of my code and still have a traditional Web form.  (I
have not tried it yet, but the changes should be minor: cutting out a
few bits of code.)

>There are basically to ways to fix that.  Use an Applet on the client
>or use Ajax. Both have serious drawbacks.
>
>What is EXTREMELY rude is to erase some of his fields or even all of
>them if he makes an error.

     Must resist urge to top.  Must,  aRRGGGHHHH!!

     What is really, really extremely rude is to erase the so-called
erroneous value and not mention it in the error message.  The user
then does not know what happened.  Did he type the value in correctly,
or did he type it incorrectly?  (For example, transposition of
adjacent characters is an easy error to make, and is common.)

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#1650

On 12-03-20 11:16 PM, Gene Wirchenko wrote:
> On Tue, 20 Mar 2012 14:28:09 -0700, Roedy Green
> <see_website@mindprod.com.invalid> wrote:
> 
>> On Tue, 20 Mar 2012 11:16:36 -0700 (PDT), Davej <galt_57@hotmail.com>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>> I have been thinking about the way I have been validating form inputs
>>> in the servelet and wonder if I would be much better off using class
>>> methods to verify these inputs?
>>>
>>> Consider that I am almost always gathering the inputs to instantiate
>>> one or more objects, but I gather and validate -- and then
>>> instantiate. Maybe I should instantiate an empty object and then use
>>> class methods to validate the inputs?
> 
>      Classes can be very useful.  They can also be a waste of time. If
> the only reason that you use classes is because you get to use
> classes, that is not a good idea.
> 
>      I recall one assignment during my degree where this got
> demonstrated rather well.  We were to write code comparing various CPU
> time allocation algorithms.  I figured out how to code it and wrote
> it.  I wrote procedural code.  There was no need for classes except
> for the one class Java requires.  One of my classmates went the OOPS
> route.  It did not work out, and he had to restart just before the
> assignment was due.  He did not get through the whole assignment.  My
> classmate was a sharp person.
> 
>      Just because you have a tool is no reason to use it.  No, I am
> not arguing not using it.
[ SNIP ]
> 
> Gene Wirchenko

One of the tensions in OOP is where to put algorithmic code, or use-case
type of code, or controller type of code. The DDD (domain-driven design)
folks would have it that domain objects have to be rich, with
practically all behaviours finding a home in methods of one domain
object or another. In this picture the classes in the
service/application layer are supposed to be seriously lightweight, with
little or no business logic.

This has been proven not to work in the real world, time and time and
time again. Inevitably there is a great deal of procedural, algorithmic
code that expresses *use case* logic and doesn't belong in domain
classes. So people - and I include myself in that large number - do what
you've described; they put this type of code in methods in "procedural"
classes. Call 'em controllers or services or whatever you like, that's
what they are - procedural.

We've tried the rich domain object approach ad nauseam, and good useful
system behaviour does *not* just "emerge" from those domain objects.
Most of the "what the system _does_" behaviour needs to be captured
outside domain classes, which latter should be reserved for "what the
system _is_" behaviour + domain state.

I've mentioned DCI (Data Context Interaction) before, and I'll mention
it again. You may not buy into it completely or much at all, and it's
not easy to implement in Java actually [1], but it's one of the few
methodologies that recognizes the fact that a lot of behaviour doesn't
fit into domain objects, doesn't belong in domain objects, and there
needs to be a systematic approach as to where to put it. Hence contexts
that orchestrate the components that belong to a use case, with
behavioural code (methods) being injected by some mechanism into barely
smart domain objects.

Here ends my little pro-DCI rant for the day.

AHS

1. Serious investigation of DCI rates the use of Ruby or Scala or C++
(or even C# - extension method approach), whatever you're most
comfortable with. Once you've got the general ideas down, then you can
try Qi4J in Java. Just my opinion as to how to tackle things.
-- 
Last week I helped my friend stay put. It's a lot easier'n helpin' 'em
move. I just went over to his house and made sure that he did not start
to load shit into a truck.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

#1652

On Wed, 21 Mar 2012 17:41:05 -0300, Arved Sandstrom
<asandstrom3minus1@eastlink.ca> wrote:

[snip]

>One of the tensions in OOP is where to put algorithmic code, or use-case
>type of code, or controller type of code. The DDD (domain-driven design)

      DINGDINGDINGDINGDING!

>folks would have it that domain objects have to be rich, with
>practically all behaviours finding a home in methods of one domain
>object or another. In this picture the classes in the
>service/application layer are supposed to be seriously lightweight, with
>little or no business logic.

     If I have clearly-defined entities that I can make classes for, I
will do so.  If I do not have that, I avoid proper classes.  At the
very least, I then avoid the clutter of unnecessary classes.
Consequently, my classes tend to be fairly heavyweight, or they are
little more than wrappers.

>This has been proven not to work in the real world, time and time and
>time again. Inevitably there is a great deal of procedural, algorithmic
>code that expresses *use case* logic and doesn't belong in domain
>classes. So people - and I include myself in that large number - do what
>you've described; they put this type of code in methods in "procedural"
>classes. Call 'em controllers or services or whatever you like, that's
>what they are - procedural.

     I consider OOP to be procedural.  The difference is how the
procedures get called.

>We've tried the rich domain object approach ad nauseam, and good useful
>system behaviour does *not* just "emerge" from those domain objects.
>Most of the "what the system _does_" behaviour needs to be captured
>outside domain classes, which latter should be reserved for "what the
>system _is_" behaviour + domain state.

     Inform is a language for writing interactive fiction (a.k.a. text
adventures).  Version 6 is very OOP.  (Version 7 went in a different
direction.)  From what I have read, it can get very messy deciding
where implementation code goes.  For example, where should the code go
to tie a rope to something?  Properties of both the rope and the other
object will be checked.

>I've mentioned DCI (Data Context Interaction) before, and I'll mention
>it again. You may not buy into it completely or much at all, and it's
>not easy to implement in Java actually [1], but it's one of the few
>methodologies that recognizes the fact that a lot of behaviour doesn't
>fit into domain objects, doesn't belong in domain objects, and there
>needs to be a systematic approach as to where to put it. Hence contexts
>that orchestrate the components that belong to a use case, with
>behavioural code (methods) being injected by some mechanism into barely
>smart domain objects.
>
>Here ends my little pro-DCI rant for the day.

     Could you please give a URL to something that explains the
basics?

>AHS
>
>1. Serious investigation of DCI rates the use of Ruby or Scala or C++
>(or even C# - extension method approach), whatever you're most
>comfortable with. Once you've got the general ideas down, then you can
>try Qi4J in Java. Just my opinion as to how to tackle things.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#1655

On 12-03-21 06:46 PM, Gene Wirchenko wrote:
> On Wed, 21 Mar 2012 17:41:05 -0300, Arved Sandstrom
> <asandstrom3minus1@eastlink.ca> wrote:
> 
> [snip]
> 
>> One of the tensions in OOP is where to put algorithmic code, or use-case
>> type of code, or controller type of code. The DDD (domain-driven design)
> 
>       DINGDINGDINGDINGDING!
> 
>> folks would have it that domain objects have to be rich, with
>> practically all behaviours finding a home in methods of one domain
>> object or another. In this picture the classes in the
>> service/application layer are supposed to be seriously lightweight, with
>> little or no business logic.
> 
>      If I have clearly-defined entities that I can make classes for, I
> will do so.  If I do not have that, I avoid proper classes.  At the
> very least, I then avoid the clutter of unnecessary classes.
> Consequently, my classes tend to be fairly heavyweight, or they are
> little more than wrappers.
> 
>> This has been proven not to work in the real world, time and time and
>> time again. Inevitably there is a great deal of procedural, algorithmic
>> code that expresses *use case* logic and doesn't belong in domain
>> classes. So people - and I include myself in that large number - do what
>> you've described; they put this type of code in methods in "procedural"
>> classes. Call 'em controllers or services or whatever you like, that's
>> what they are - procedural.
> 
>      I consider OOP to be procedural.  The difference is how the
> procedures get called.
> 
>> We've tried the rich domain object approach ad nauseam, and good useful
>> system behaviour does *not* just "emerge" from those domain objects.
>> Most of the "what the system _does_" behaviour needs to be captured
>> outside domain classes, which latter should be reserved for "what the
>> system _is_" behaviour + domain state.
> 
>      Inform is a language for writing interactive fiction (a.k.a. text
> adventures).  Version 6 is very OOP.  (Version 7 went in a different
> direction.)  From what I have read, it can get very messy deciding
> where implementation code goes.  For example, where should the code go
> to tie a rope to something?  Properties of both the rope and the other
> object will be checked.
> 
>> I've mentioned DCI (Data Context Interaction) before, and I'll mention
>> it again. You may not buy into it completely or much at all, and it's
>> not easy to implement in Java actually [1], but it's one of the few
>> methodologies that recognizes the fact that a lot of behaviour doesn't
>> fit into domain objects, doesn't belong in domain objects, and there
>> needs to be a systematic approach as to where to put it. Hence contexts
>> that orchestrate the components that belong to a use case, with
>> behavioural code (methods) being injected by some mechanism into barely
>> smart domain objects.
>>
>> Here ends my little pro-DCI rant for the day.
> 
>      Could you please give a URL to something that explains the
> basics?
> 
>> AHS
>>
>> 1. Serious investigation of DCI rates the use of Ruby or Scala or C++
>> (or even C# - extension method approach), whatever you're most
>> comfortable with. Once you've got the general ideas down, then you can
>> try Qi4J in Java. Just my opinion as to how to tackle things.
> 
> Sincerely,
> 
> Gene Wirchenko

At some point you pretty much have to read the seminal article:
http://www.artima.com/articles/dci_vision.html.

It helps to read this again from time to time as you experiment. Also,
the example they use (which has become semi-canonical) sucks, in my
opinion. They could have done considerably better. It can also be
worthwhile to peruse the discussion (click on the Discuss link at the
bottom).

This Groovy-based article is quite good:
http://victorsavkin.com/post/4243788839/dci-in-groovy

For further material follow from
http://stackoverflow.com/questions/3879348/examples-of-dci-architecture.
From that batch the article at
http://pettermahlen.com/2010/09/10/dci-architecture-good-not-great-or-both/
is quite good; he asks some good questions and isn't blindly accepting
of everything.

One of the main ideas behind DCI is to make the algorithm a first class
citizen, or as much as you can in your particular language. Rather than
having the business logic that pertains to the next button click in your
MVC web app be scattered all over several dozen methods in 5 or 10
classes, not to mention each class being a grab bag of methods to handle
every possible situation that the object of said class has to
participate in, business logic ends up in "role" methods that are
assigned to much leaner domain objects by the context depending on the
specific use case.

DCI is about *object* oriented programming, not about class oriented
programming. I actually bleat on about this at
http://exvalle.blogspot.ca/2012/03/more-notes-on-dci.html

AHS
-- 
Last week I helped my friend stay put. It's a lot easier'n helpin' 'em
move. I just went over to his house and made sure that he did not start
to load shit into a truck.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

#1660

On Wed, 21 Mar 2012 17:41:05 -0300, Arved Sandstrom
<asandstrom3minus1@eastlink.ca> wrote, quoted or indirectly quoted
someone who said :

>One of the tensions in OOP is where to put algorithmic code, or use-case
>type of code, or controller type of code. The DDD (domain-driven design)
>folks would have it that domain objects have to be rich, with
>practically all behaviours finding a home in methods of one domain
>object or another. In this picture the classes in the
>service/application layer are supposed to be seriously lightweight, with
>little or no business logic.

Back in 1979  I devised a language called Abundance, a superset of
Forth. It was intended primarily for validation of data entry.

It had 50+ built in data types.  In the declaration you did such
things as specify
1. a range low..high for numeric and date and the language dealt with
ensuring that bound was honoured, including displaying that info on
status line whenever the user keyed that field.
2. whether lower, upper, accents, symbols etc were permitted in a
string.  If no accents, keying transformed accented letters to
unaccented one, lower to upper etc.
3. It knew what a province/state, legal postal code, phone number,
currency, area code etc  looked like for Canada, USA, Sweden, India It
had tables that had to be updated every few months.

Procedural validation was done is the form of assertions.  If an
assertion failed, the program "jaunted" back in time to a previously
saved state and let the user have another go at it without losing
keying.  The user could jaunt back even further if the problem was not
with the suspected "culprit" field.

I moved the data display, validation and keying rules from apps to the
language (or what we would now call the standard classes).
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It is almost impossible to keep things in synch manually. Instead: 
-Keep each fact in only one central database (not necessarily SQL),
and access it as needed. Since there is only one copy of each fact, 
there is nothing to get out of synch.
-Use some automated tool so that if you change a fact is one place,
it automatically updates the others.
-Write a sanity checker you run periodically to ensure all is consistent. 
This is the strategy compilers use.
-Document the procedures needed to keep all in synch if you change 
something and rigidly and mechanically follow them.

[toc] | [prev] | [next] | [standalone]

#1654

Gene Wirchenko wrote:
>      Classes can be very useful.  They can also be a waste of time. If
> the only reason that you use classes is because you get to use
> classes, that is not a good idea.
> 
>      I recall one assignment during my degree where this got
> demonstrated rather well.  We were to write code comparing various CPU
> time allocation algorithms.  I figured out how to code it and wrote
> it.  I wrote procedural code.  There was no need for classes except
> for the one class Java requires.  One of my classmates went the OOPS
> route.  It did not work out, and he had to restart just before the
> assignment was due.  He did not get through the whole assignment.  My
> classmate was a sharp person.

Given that we only hear this through the filter of your interpretation, it's not very evidentiary. Without seeing the exact problem and where your friend (however sharp he may have been) went wrong, there's simply not enough here to blame "classes" for his failure. On the face of it, his problem seems much more likely to have been his and not classes'. Sometimes a person gets off on the wrong algorithmic foot, or maybe he just didn't understand object-oriented programming yet well enough to get it right. Whatever the actual facts, I remain extremely skeptical that it was classes' fault.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#1657

On Wed, 21 Mar 2012 14:56:38 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote:

>Gene Wirchenko wrote:
>>      Classes can be very useful.  They can also be a waste of time. If
>> the only reason that you use classes is because you get to use
>> classes, that is not a good idea.
>> 
>>      I recall one assignment during my degree where this got
>> demonstrated rather well.  We were to write code comparing various CPU
>> time allocation algorithms.  I figured out how to code it and wrote
>> it.  I wrote procedural code.  There was no need for classes except
>> for the one class Java requires.  One of my classmates went the OOPS
>> route.  It did not work out, and he had to restart just before the
>> assignment was due.  He did not get through the whole assignment.  My
>> classmate was a sharp person.
>
>Given that we only hear this through the filter of your interpretation,
 it's not very evidentiary. Without seeing the exact problem and where

     Oh, no!  I forgot to attach the affadavits.

>your friend (however sharp he may have been) went wrong, there's simply
 not enough here to blame "classes" for his failure. On the face of
it, his problem seems much more likely to have been his and not
classes'. Sometimes a person gets off on the wrong algorithmic foot,
or maybe he just didn't understand object-oriented programming yet
well enough to get it right. Whatever the actual facts, I remain
extremely skeptical that it was classes' fault.

     Well, he was into Java's features on that assignment.  At one
point, he said that he was using comparators.  I can not see what he
was using them for.  I am assuming he was into classes since
presumably, using comparators made sense to him.  I suspect that the
shiny got him.

     I looked for how to use classes, but just did not see any way
that they would be helpful on the assignment so I did not use them.
Some people would anyway.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#1658

On 3/21/12 7:09 PM, Gene Wirchenko wrote:
> On Wed, 21 Mar 2012 14:56:38 -0700 (PDT), Lew<lewbloch@gmail.com>
> wrote:
>
>> Gene Wirchenko wrote:
>>>       Classes can be very useful.  They can also be a waste of time. If
>>> the only reason that you use classes is because you get to use
>>> classes, that is not a good idea.
>>>
>>>       I recall one assignment during my degree where this got
>>> demonstrated rather well.  We were to write code comparing various CPU
>>> time allocation algorithms.  I figured out how to code it and wrote
>>> it.  I wrote procedural code.  There was no need for classes except
>>> for the one class Java requires.  One of my classmates went the OOPS
>>> route.  It did not work out, and he had to restart just before the
>>> assignment was due.  He did not get through the whole assignment.  My
>>> classmate was a sharp person.
>>
>> Given that we only hear this through the filter of your interpretation,
>   it's not very evidentiary. Without seeing the exact problem and where
>
>       Oh, no!  I forgot to attach the affadavits.
>
>> your friend (however sharp he may have been) went wrong, there's simply
>   not enough here to blame "classes" for his failure. On the face of
> it, his problem seems much more likely to have been his and not
> classes'. Sometimes a person gets off on the wrong algorithmic foot,
> or maybe he just didn't understand object-oriented programming yet
> well enough to get it right. Whatever the actual facts, I remain
> extremely skeptical that it was classes' fault.
>
>       Well, he was into Java's features on that assignment.  At one
> point, he said that he was using comparators.  I can not see what he
> was using them for.  I am assuming he was into classes since
> presumably, using comparators made sense to him.  I suspect that the
> shiny got him.
Using "Comparators" makes sense if you need to order Object's of a class 
that isn't "Comparable", or if you need a different order than the 
"Comparable" provides.  Given this was an assignment, I doubt he had 
full experience in what the best approach was. He may not have needed 
Comparators or Comparables. I can't be certain unless I was given the 
actual assignment my self.  There are often multiple ways to solve a 
particular problem, and there are often problems you don't see until you 
have years of experience (along with being a "sharp" person).

>
>       I looked for how to use classes, but just did not see any way
> that they would be helpful on the assignment so I did not use them.
> Some people would anyway.
That tells me two things. One, you didn't see how classes would be 
useful. Two, you found an alternative.

There are always alternatives, but they usually have trade-offs.  The 
benefits of classes really come when you have long-lived and/or 
large/complex projects.  When you need to (say) parse through a log file 
once to verify something, building a fully OOP solution seems like 
overkill.  I might go as far to say Java is overkill for that task 
(though it depends on what the analysis is).  On the other hand, if 
you're developing a web application that takes different inputs (user 
form submissions, databases, etc...), OOP provides a huge benefit over a 
pure procedural program.

Really, it doesn't matter if you go for "classes" or "methods", the real 
benefit comes from modularity, encapsulation, and isolation.  One very 
important characteristic of a modular program is the ability to change 
the behavior of your "system" with as few side-effects as possible.  It 
is possible to fail this with OOP, but its harder to succeed with 
Procedural programming.

Hope this helps,
Daniel.

[toc] | [prev] | [next] | [standalone]

#1659

On Thu, 22 Mar 2012 08:36:43 -0700, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

[snip]

>Really, it doesn't matter if you go for "classes" or "methods", the real 
>benefit comes from modularity, encapsulation, and isolation.  One very 
>important characteristic of a modular program is the ability to change 
>the behavior of your "system" with as few side-effects as possible.  It 
>is possible to fail this with OOP, but its harder to succeed with 
>Procedural programming.

     I have my doubts about that.  If you use the discipline of all
procedures using only local data or parameters, then you will have
excellent decoupling.  Objects can muddy that up.

     Either way you go, there is no panacea.  It is important to have
the discipline to stick to something workable in the long-term and not
to hare after quick fixes.

     Unless one's system is a simple or temporary one.  Beware of
systems becoming less simple as features are added.  Beware of
temporary systems becoming permanent.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.help

csiph-web