Design Patterns - Confused !

[Shivaji Bhosale]

Hi Peter,
You know I feel myself in the confused state.
I started, by considering server design approach first. My Locking Unlocking mechanism over server is stable.
Right now Lock / Unlock methods are present in the Data class. Instance of Data class is bound to the RMI Registry.
But I am unnecessarily getting confused while people extending Data class for Local & Remote operation. In my case personally I feel, overloading some methods within Data class can satsify mine local mode of operation, instead of applying Factory or Adapter pattern at server. That way, by avoiding Design Patterns, I feel I am keeping my application much simple.
By doing this I am not introducing additional interfaces. So usage design patterns is avoided. I am doing so bcoz i am not having good background of Design Patterns. I feel instead of doing something half cooked, better do something on which you can be very confident.
I have created Session Id pooling at server to identify client who locked record, I need to see if pooling comes under any well known Design Patterns or not.
What do you think, avoiding Design patterns will help me out ?
I am eagerly waiting for sincere opinions from the group.

[kerry shih]

There is no problem in simplicity. However despite all the normal advantages that patterns give you such as extensibility and maintainability, I find that patterns help modulate code into incredibly logical blocks. If you find that there is a lot of code in any given class then you can expect to have problems with maintanence and reuse. While many people preach these benefits I find from a practical point of view that I spend far less time making changes and feel much more confident regarding the readability of the code. My old style of programming used somewhat cheaper solutions and I would always get frustrated when I had to come back to the code later.
On a technical note. If you have different interfaces for communicating remotely versus locally then your client code is going to have to "if" around whether they want to communicate over the wire or not. For instance:
if (useRemote)
deleteRemote();
else
delete();
A general principal of coding is to keep away from tying your different tiers code to each other. Now if the basic signature of a method changes you have to change it twice in the data class and twice in the client.
Hope this helps
Kerry