• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How Simple is Simple?

 
Thomas Hubschman
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I know I supposed to keep it simple, but does that mean where I see opportunities for reusability we should ignore them?

In other words, parts of my URLyBird project is screaming out to have its data file access code generalized (plus I kinda think the code would be convenient to use in future Swing prototypes for clients).

Is it ok to generalize it or will I loose points by making the code potentially harder for "Junior Programmers" to understand.

Thanks,

Tom
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Thomas,

Originally posted by Thomas Hubschman:
I know I supposed to keep it simple, but does that mean where I see opportunities for reusability we should ignore them?


Your question itself hint that you yourself are not sure anymore whether your solution is a simple one or not .

So it's fine that your Alarm bell ring. The term reuse is maybe one of the most overloaded terms.

My project had 23 Java classes all in all. My main focus was on the architecture which was driven by some wellknown GoF patterns. If you follow these patterns then you do reuse if you want or not . These patterns already have all these common design principles implicitely in them. I understand reuse (and I did well in my SCJD) at the level of how design patterns realize things. And not by making nonsense abstraction of anything.

If your approach is going for the sake of readibility, rethink the whole design and keep things more cohesive or simple

Regards,
Darya
 
Thomas Hubschman
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Darya,

I also am following GOF patterns . I am glad to hear that you did too and it did not apparently over complicate your submission.

Let me cut to the chase and tell you how I think I am **probably** over engineering the system....

I made the implementation of the supplied DB interface sufficiently smart to read ANY file that has the broad format in the supplied flat file database, in other words, these three sections.

1. Data File Header
2. Database Schema
3. Database Contents

At runtime, the DB implementation parses the Data File Header and Database schema and then loads the Database Contents based up the metadata that it found in the previous sections. This is (apparently) unnecessary code, except for the fact that it would allow the database schema to be altered without rewriting the middle tier of the application. The View may have to change although maybe not if the additional field could be expressed as an additional column.

I would do this in a production app because clients ALWAYS change their data requirements and I would try to avoid having to recode my DataAccessObjects and TransferObjects. Especially in a case like this where everything is String data.

I have just started the project ( < 12 hours work ). I think based on the postings of other ranchers that I should NOT follow this path described above, but rather hard code the parsing of the data file and hard code the UI to accept the 7 fields that my particular database contains.

Is that right?

Regards,

Tom
 
Lucy Hummel
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tom,

When I started I did the same as you did:

parsing the database schema and private generic db processing.

Since a lot of guys in the forum did hard codes the stuff and Sun did not told me in my requirments anything of generic db access, I hard code the database schema.

I hope that is fine with my requirements that Sun gave me.

Please decide by yourself, is it okay for your side.

Br, Lucy
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Thomas Hubschman:
I would do this in a production app because clients ALWAYS change their data requirements and I would try to avoid having to recode my DataAccessObjects and TransferObjects. Especially in a case like this where everything is String data.


It sounds all good to me except the quote above. I don't get what you mean. Do you pipe TransferObjects through your layers, or do you plan to do so?

Regards,
Darya
 
Thomas Hubschman
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Daria & Hummel,

Yes I am planning on piping Transfer Objects between the layers. Right now I am imagining that the Transfer Objects are not strongly typed JavaBeans but are more like a Tree Set with the field name as the key and the field value as the value.

In a production app, this would allow for the addition of new fields to the db without requiring much code elsewhere to be changed.

Again, this seems though, based upon the threads I have read in this forum, the way NOT to go. I mostly work on the weekends, so I can wait a few days to make my decision.

I very much appreciate your input!

Thanks,

Tom
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Thomas,

I was in mid of writing you an answer when my Dell Laptop's graphic card crashed .

So sorry for the delay I'm going to write you answer from another computer now .

I am not going to tell you my solution, because that would break all the fun with this cert.

Why do you use Transfer Objects? Do you think a Transfer Object is the only way?

Regards,
Darya
 
Thomas Hubschman
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Darya,

I guess I chose Transfer Objects because that pattern is what I am most used to using for transferring data between layers in the various projects I have worked on. (Mostly J2EE stuff, but a Windows Forms App in C# more recently).

I was planning the app on looking something like this. (The Transfer Objects are not shown as that would exceed my ASCII UML modeling ability:



Does that make sense?

Thanks again!

Tom
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Thomas Hubschman:
(The Transfer Objects are not shown as that would exceed my ASCII UML modeling ability:




Your ASCII UML abilities are already perfect . I love this FileStorage .

You say you use TransferObjects because you do so in J2EE. But beware here you are not at the J2EE front. Your solution (and the patterns behind) must be based on pure J2SE .

Regards,
Darya
 
Thomas Hubschman
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the help everyone!
[ April 06, 2007: Message edited by: Thomas Hubschman ]
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are welcome
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic