For New Guys, Simpleton pattern revisited...

Question

In the March 2004 issue of Java Patterns there is an article called "OO Patterns for Extensive Coding With OverTyping and Generic Exclamations". The article introduces the simpleton pattern, citing a similar pardigm in the C programming world. Using the simpleton pattern the following code,
* Test.java
* Created on May 14, 2004, 2:54 PM
package tmp;
* @author  awaddi
public class Test
     private int _pNumberOfFileWritesInt;
     private int _pNumberOfFileReadsInt;
     /** Creates a new instance of Test */
     public Test()
          _pNumberOfFileWritesInt = 0;
     public void write( Object data )
          // write the data
          set_pNumberOfFileWritesInt(  get_pNumberOfFileWritesInt() + 1  );
     public void read( Object data )
          // read the data
          set_pNumberOfFileReadsInt(  get_pNumberOfFileReadsInt() + 1  );
      * Getter for property _pNumberOfFileWritesInt.
      * @return Value of property _pNumberOfFileWritesInt.
     public int get_pNumberOfFileWritesInt()
          return _pNumberOfFileWritesInt;
      * Setter for property _pNumberOfFileWritesInt.
      * @param _pNumberOfFileWritesInt New value of property _pNumberOfFileWritesInt.
     public void set_pNumberOfFileWritesInt(int _pNumberOfFileWritesInt)
          this._pNumberOfFileWritesInt = _pNumberOfFileWritesInt;
      * Getter for property _pNumberOfFileReadsInt.
      * @return Value of property _pNumberOfFileReadsInt.
     public int get_pNumberOfFileReadsInt()
          return _pNumberOfFileReadsInt;
      * Setter for property _pNumberOfFileReadsInt.
      * @param _pNumberOfFileReadsInt New value of property _pNumberOfFileReadsInt.
     public void set_pNumberOfFileReadsInt(int _pNumberOfFileReadsInt)
          this._pNumberOfFileReadsInt = _pNumberOfFileReadsInt;
     public static void main(  String[] args  )
          Test aTest = new Test();
          // write twenty lines to a file
          while(  aTest.get_pNumberOfFileWritesInt() < 20  )
               aTest.write(  "a line"  );
               System.out.println("Reads: " + aTest.get_pNumberOfFileReadsInt()  );
               System.out.println("Writes: " + aTest.get_pNumberOfFileWritesInt()  );
          System.out.println("Done!");
          System.exit( 0 );
}could be replaced using the Simpleton Pattern. Though the article was complex, I believe it raised some salient points, particularly in regard to many current idioms that new programmers are faced with. While the above code example demonstrates several principles that are important for new programmers to adhere to, a la "Ultimate Java Coding Style and Superb Idioms for Defensive Programming", the Simpleton Pattern utilises a different approach:
class ReadWriteCounter
     public int reads = 0;
     public int writes = 0;
     public void write( Object data )
          // write the data
          writes++;
     public void read( Object data )
          // read the data
          reads++;
     public static void main(  String[] args  )
          ReadWriteCounter counter = new ReadWriteCounter();
          // write twenty lines to a file
          while(  counter.writes < 20  )
               counter.write(  "a line"  );
               System.out.println("Reads: " + counter.reads  );
               System.out.println("Writes: " + counter.writes  );
          System.out.println("Done!");
          System.exit( 0 );
}While the Simpleton pattern is useful, it has some disadvantages:
When you sell your programmes, other programmers will be able to modify the internal state of your classes.
Synchronisation of variable access can only be achieved by using volatile members, this is inherently error-prone as volatile variables are often guaranteed to provide semi-deterministic member access and may change the values of variables in common circumstances (never use the volatile keyword, it is dangerous).
The use of C-like structs is likely to cause many programming errors, contrary to popular belief, int[] z; (z[0]+4) = 22; will not assign the value of 22 to the second item in the z array. Java uses object references, NOT ADDRESS POINTERS.
So when is the Simpleton pattern a bad thing? In years of Java programming I have found that in 99% of the cases the Simpleton pattern is all that is needed, however, when referring to references of Objects that are shared between classes, the normal getter/setter is really useful. Consider:
class ResultCode
     String value;
     public ResultCode( String s )
          value = s;
class FileOperationA
     ResultCode code;
     public FileOperationA(  ResultCode c  )
          code = c;
     public void someOp()
          System.out.println("code:" + code.value );
class FileOperationB
     ResultCode code;
     public FileOperationB(  ResultCode c  )
          code = c;
     public void someOp()
          System.out.println("code:" + code.value );
class DirectoryOne
     FileOperationA a;
     FileOperationB b;
     public DirectoryOne()
          ResultCode c = new ResultCode( "OK" );
          a = new FileOperationA( c );
          b = new FileOperationB( c );
          // a and b share a reference to an underlaying object, not a primitive
     public void changeCodeString()
          a.code = new ResultCode(  "It's all good" ); // replaces OK as the message, but just for a
          // now a and b have different code values, wrong
     public void changeCodeString2()
          a.setCode( "It's all good" ); // replaces OK as the message, for a and b Yay!!
          // now a and b have (still) the same code values, right
}The getter/setter is necessary because we aren't using primitives in ResultCode, we have a shared reference through a and b that references a reference, and because we want operations through either a or b on a shared ResultCode object to be visible to both "copies" of the object (they aren't copies, its the same object, two referents).
Its a little complicated, but suffice it say that the jist of the article is to keep it simple unless you are really certain that you need the complexity.
Andrew

Answer 1

An object with just behaviour doesn't do much, in the
case of an object with static methods that modifies
data passed in via arguments (which, incidentally,
seems to be the model you are suggesting), the object
itself is simply a utility grouping and doesn't have
any state to behave with.
As I said an OO Object must have data and behavior.
If it doesn't have data it is not an Object. That is not to say that you can not create code that does that, but rather that it is not an OO Object.
Most objects have at least two kinds of values,
internal values that don't compose the behaviour of
the object, things like loop counters, computation
constants, or intermediate values; not really data is
it? There are also values that do compose state, alter
behaviour, or provide information; things like number
of logins, name of a data file, etc...Local variables are not Object data. Via the implementation code a java class (for example) might have member variables that are used to achieve some implementation goal yet are not actually part of the Object.
>
Then there is the actually interesting stuff, the
raison d'etre of the object, values that represent the
output of the object and, actually deserve to be
called data: total monthly bill, number of available
routes, installed packages, or whatever.
Let's say we have three kinds of values; temporary,
intermediate, and product or, perhaps, transient,
volatile, and final. It should be pretty clear that
any client or co-programmer shouldn't be concerned
with temporary or intermediate data and that it
shouldn't be exposed, however, it should also be
pretty clear that the resultant data, or product of an
object, should be (in fact, as I have been arguing)
must be exposed, why else have the object in the first
place?As I already said if most of the classes in the system expose their data then something is wrong with the design.
DTOs are an excellent example of classes that expose all of their data. Yet in the total system, a single DTO can normally be expected to have 4 or more classes for each DTO. And those classes do not expose their data.
>
My arguments also come out against under-exposing the
intermediate values in an object, certainly within a
package, exposing data to related co-objects is
probably not much of a fault, except where it concerns
someone who says, "Hey, those values in Class Z could
be modified by Class B!"
Exposing data is always dangerous for two reasons.
1. The original developer might not have know what they were doing and thus instead of creating an Object they created something else (like half an Object, or two Objects in one, etc.)
2. The maintainance programmer might not understand the original design. Exposed data allows them to avoid this lack of knowledge. Thus instead of figuring out that the intent of the design or figuring out that the design must be refactored (after understanding it the first place) they use a kludge that the exposed data allows for.
Of course, the proper response is, "Hey!! Don't modify
intermediate values in class Z from Class B!!",
problem solved. No patterns, programming paradigms, or
rules of practice (which generally come out as do this
or perish!) necessary. It is simpler, and because of
that I would argue that it is faster, less prone to
error, and more enjoyable for the programmer to work
with as a result.
If everyone was a perfect programmer there would be no problems.
Since they are not, one must use what is available and what is practical to prevent those problems that are likely to occur.
And given that the intent of most programmers is tomake money with their code (or expose it via the
public domain) all of those people should learn how to
write code in terms of other people.
So exposing data is wrong for most of the people here.Clearly not true just because you said so.
No not true because you disagree.
Hard to tell what you are disagreeing with here though. That most developers want to make money and/or acclaim for their work?
>
>
Nothing I have seen so far is even close tosuggesting that your hypothesis is correct. And there
is at least indirect evidence that it is incorrect.
This was a rebuttal to your original point that stated
that 90% of development time was spent refactoring and
bug-chasing, which I agreed with and pointed out that
reducing code size and complexity by avoiding
unnecessary code (designed to avoid data-exposure or
designed for policy-adherence) would reduce the number
of hours represented by "90%" by a corresponding
amount.Again that is a hypothesis of yours. And current known scientific studies do not seem to support it.
>
You say there is indirect evidence arguing against??
Yes. Goto's can make code more dense and yet harder to understand and maintain. Because of that gotos are no longer used. Your hypothesis would suggest that gotos should be a good thing in the language (because the code is shorter.)
>
That is non-sensical in terms of this discussion.
An Object in terms of OO has 'data' and 'behavior'.The 'data' should be 'encapsulated' and 'hidden' by
the Object.
See the top of this post. Hiding your data is like
saying we have your bill, we know what your monthly
statement is but we can't tell you and so we sent you
that blank one...
Part of the problem is that a class tends to have many
different types of "data". A local, temporary loop
counter would be really difficult to work with if it
was exposed and modified from outside the scope of an
object.
Again let me point out that your response is non-sensical.
A local member variable is not data for the Object.