This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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
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 ]
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