Re: advise on best practices guides and projects

Mark Space wrote:


I see now, that I might have been a bit unclear in my original question.
Maybe because in my head there where too many questions and I was unable
to sort the properly and ask the right question.

Sure, I have many of the quality OO books, such as Head First Patterns,
J2EE Design Patterns, AntiPatterns. In addition to Effective Java,
Elements Of Java Style, Refactoring and several UML books.

But I feel those books in many respects are too high level for my
problems. They tend to aim for architectural issues instead of practical
OO programming. What I am looking for is on a lower level, i.e. more
conventional OO programming idioms and so on.

Many of the books are also very generic in their explanations and use
contrived example such as "A mammal is a dog or a cat" or examples that
only apply if you create software that is so complex or so reusable that
it could only be used in a NASA project. Many of the things I read in
those books, I never end up using. Mostly because its depends on an
architecture or a design which in most cases is too complex for needs of
the projects I am doing.

Here is where I feel I might be missing something, I program true KISS
style (also known as pragmatic programming) where:
- I dont create an generalised interface unless I know it will be reused
in the next 1-6 months.
- I use as as few external libraries as possible, usually 5-10.
- I dont use XML unless its for machine to machine communication.
- I dont use domain models just for the sake of it.
- I use collections, but only because its easier to code and maintain
than to create an object wrapper around some arrays. Even though
collections uses approx 5 times more memory than an array and hence
cause traversal to be 5 times slower (my own measurments).

I have the feeling that because of these design decisions I end up with
a design that does not lend it self to OO very well, but at the same
time there is no point in creating something complex because of some
programming principles. This is why I wanted to look at something
somebody else had programmed, so I could see the good ways of doing
basic OO code.

I usually code store-and-retrieve servers connected to an sql database.
There usually isn't much domain logic, but there is some data model
conversions and all the stuff needed for technical reasons, such as
exception handling strategies, caching, connection pools, input
checking, data retrieval logic etc. So the issues I mostly end up
discussing with my self is not whether to use abstract factory,
strategy, decorator etc, but rather

- should this argument be expressed as a collection or as a container object
- what the point in encapsulating this object when what the object
stores is really just simple pieces of data which requires no real
domain logic to manipulate.
- should I use parameter objects for the arguments when the object is
really just a dto and I cant see the argument changing any time soon.
- how should I express this return value
- should I use a global environment object or give the environement as
an argument to the method or to the objects constructor.
- should I use a constructor or should the methods just be static.
- do I need a domain layer or should the SOAP facade layer talk directly
to the db facade layer.
- is there any smartness to this domain object or is it really just a
dto domain object? can I make it any smarter? is there any real need?

The problem is that a lot of the time I think to myslef that the code
could be done much simpler if I remove this and that, but then I would
end up with mostly static stuff and no real objects (or "not so 'smart
objects'")

I feel I am missing the entire OO basics that make me want to do things
in correct OO.

Any ideas on where to look for help on these types of issues or some
case studies/projects that can help me learn this kind of stuff.


Thanks, I will have a look at it, allthough gui lends it self much more
to OO than e.g. a transacation server or a database based application
server.

regards

tom