• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Data class

 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is my first time on SCJD forum, so hello everybody!

I've got a question. Do you think it's a good idea to move data file handling code to another class. In that case only locking mechanism would be implemented in Data class. As for file handling, Data would delegate calls to methods of FileHandler class.

Thanks for answer,
Pawel
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Pawel,

Welcome to JavaRanch and this forum.

Personally I would go a step further, and have a separate class for the locking as well. But that is my personal choice.

Take a look at the Facade Design Pattern. Sound familiar? What we are discussing is such a common thing to do that there is a design pattern to express what has been done. Or to put it another way, if you did have a class for your lock methods, you could go into a design meeting and say "the Data class is a Facade for the FileHandler and LockHandler classes" and most of the members of the meeting would know exactly what the Data class does and would be willing to move onto the more important classes.

In practical terms, splitting the classes like this means that each class is responsible for only one thing. If you want to work on record retrieval, you know exactly what class to go to - you do not have to worry about what all the variables and methods for lock handling are doing. A cleaner class is easier to maintain.

Regards, Andrew
 
Pawel Poltorak
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

Indeed, separation is what I'm after . I must admit, that I've not considered using separate class for locking, but now I will make one. Thanks for advice .

Pawel
 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Andrew, Pawel,

I agree the class can be made more maintainable by using the facade pattern as Andrew suggests.

Andrew, when you say:


Personally I would go a step further, and have a separate class for the locking as well. But that is my personal choice.



Are you thinking in the context of a real-world application or the SCJD assignment? In the real world I believe certainly you would want to seperate out this functionality into seperate classes, however in the SCJD I am not so sure.

Firstly let me say I belive you could pass SCJD with flying colours with either using the facade pattern in relation to Data and locking/file handling or by putting all this code into your Data class.

Seeing as I don't have to maintain this class and my SCJD instructions state (with my emphasis):


The IT director does not anticipate much reuse of the first Java technology system, but intends to use that system as a learning exercise before going on to a web based system.



and...


Clarity and Maintainability
A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one, even if the complex one is a little more efficient. Code complexity, including nesting depth, argument passing, and the number of classes and interfaces, should be reasonable.



I choose not to implement seperate classes for this functionality and put it all into the Data class as I certainly can readily understand the project better with all this functionality in the Data class. I will use the above excerpts from my instructions to justify my choice.

Granted I couldn't maintain/re-use my Data class as readily, but this is not a requirement.

Best Regards,

Czarak.
 
Andrew Monkhouse
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Czarak,

Originally posted by Czarak Ynehac:
Firstly let me say I belive you could pass SCJD with flying colours with either using the facade pattern in relation to Data and locking/file handling or by putting all this code into your Data class.

Absolutely!

But just to play devil's advocate, changing the emphasis on the instructions:

From the instructions:
Clarity and Maintainability
A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one, even if the complex one is a little more efficient. Code complexity, including nesting depth, argument passing, and the number of classes and interfaces, should be reasonable.

I think it can be readily argued that having separate classes will make the design clearer .

But having a Facade does not guarantee that you will have a clear design. And having all the code in one class does not guarantee that it will be easier to understand by the junior programmer. In my opinion, neither option has a sure-fire case that mandates their use. Both are equally valid positions. So it comes down to preference, and my personal preference is for each class to have only one responsibility (note the italics: that is my preference, not yours, not the assessors - just mine).

Regards, Andrew
 
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,

I have also URLyBird and I do the same, or even a little bit more. I have a
DataScheme - here are the database magic cookie, records pointers, record fields pointers, in one word all the record arithmetics.
DataAccess - using the DataScheme I access the records(fields)
LockManager - here I manage concurrent access
PizzaHut - here I order (sometimes) Pizza

I melt all together (facade pattern) in to the Data class.
Note : When I use pointer I mean File pointer from RandomAccessFile.

The only "problem" is that you have more source files to manage.

I don't use any extreme complicated patterns/thenique I just apply the basic principle "encapsulate what varies" - any junior programmer must know this.

Regards, Mihai
 
Andrew Monkhouse
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mihai Radulescu:
PizzaHut - here I order (sometimes) Pizza



ROFL
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic