wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Designing to Interfaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Designing to Interfaces" Watch "Designing to Interfaces" New topic
Author

Designing to Interfaces

dean tomlinson
Ranch Hand

Joined: Jan 31, 2002
Posts: 94
what's people's thought's on desigining to interfaces in this assignment - and doing it to sensible level.
i am consious that the whole point of this cert, is to test our software design skills, it is not about developing the most functional system - as i have read time and time again - leave things out that aren't explicitely asked for - even though they would make for a better system)
very briefly, by desigining against an interface (such as DataAccess) rather than an implementation class (such as Data), the implementation of DataAccess can be changed from Data to RemoteData to another implementation of a database, perhaps based on a DBMS.
the problem is, i think that the methods of the DataAccess interface should be returning interface types, and taking interface types as method parameters.
if we did want to change to a DBMS implementation of DataAccess, and it's methods remain hard wired to return DataInfo and FieldInfo etc I doubt it would work.
basically my question is, how far do we take the designing against interfaces ideal?
is it out of scope of this assignment to re-design the DataInfo and FieldInfo, so they are implementors of more generic interface's, and then use these in the DataAccess interface? or is this going to just overcomplicate things ? for the scope of this assignment.
to be honest i very rarely design against interface in the work i do in the "real" world, but i'm not expert (which is why i'm doing this cert !)
any suggestions / comments is as always, greatly appreciated .
cheers, dean
Sai Prasad
Ranch Hand

Joined: Feb 25, 2002
Posts: 560
I am not sure if you violate any rules as far as this assignment is concerned. But I can think of two ways this assignment can be extended in the future with the current technologies.
1) Use a J2EE application server, EJBs and move the business logic to the server with RDBMS.
In that case, it is going to be a complete rewrite except for the GUI components.

2) Keep the existing architecture and use RDBMS.
You can still query the RDBMS and convert the results to DataInfo and FieldInfo objects.
So I wouldn't worry about abstracting the DataInfo or FieldInfo to an interface.
[ May 10, 2002: Message edited by: Sai Prasad ]
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17257
    
    6

is it out of scope of this assignment to re-design the DataInfo and FieldInfo, so they are implementors of more generic interface's, and then use these in the DataAccess interface? or is this going to just overcomplicate things ? for the scope of this assignment

In this case, yes it is out of the scope to change it.
You are right about using Interfaces for many things. but here is where your ideas is just a little too far, or should I say here's a suggestion to get your wish and not have to go too far.
You have your DataAccess interface, hence you have design by Interface. Then for the GUI you create a Facade class that the client will use. The client calls this Facade class with methods like BookSeats(). Now the client knows nothing about DataInfo, or any of those other clasees. So now when you change the DataBase, you only need to change the Facade class, and everyone is happy.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Designing to Interfaces