I'm thinking of implementing custom business types for attributes belonging to a flight entity (flightnumber, price etc). Admittedly, at present, constraints on these types are not needed/possible since the only types related to flight that is inputted in the GUI is origin and destination. But none of these types has any constraints specified in the assignment description. The constraints cannot be deduced by looking at a database dump in my opinion. However, my rationale is to suport future enchancements by a small type framework. The idea behind this framework is that both the businesslogic tier in the client and the GUI-model will share these types so that future constraints on these types could be implemented in one place. Furthermore it "feels" wrong to expose for example DataInfo as the returntype from a business method. My problem now is that several custom types would basically be a kind of String (or Float or Integer) with support for future additional constraints. However String is final so I cannot use String by inheritance. Another solution is to create an abstract StringType which implements all the interfaces that String implements. The StringType then delegates all the necessary methods to an internal String attribute. Furthermore the StringType would also have an abstract private method that would validate the argument to it's constructor before creating an instance of StringType. Now, to create the custom business type FlightNumber one would inherit from StringType and implement the abstract validate method in FlightNumber. Q1) do you consider this as a design supporting the requirements in the assignment? Q2) Is this an ok way of supporting custom business types in a system in general? If not could you point me to an alternative approach? Q3) Why are all the wrapper types final in Java? It forces me into a much more code intensive approach that also seems a bit awkward.
Alexander. Here is my typical answer. Why add this complexity, when it isn't in the requirements? The business methods returning DataInfo is quite alright. You can have a Facade class for the client to hide the implementation of these database methods. Mark
Mark, yes you're right, it's hard justifying this approach given the requirements. I guess I just hoped that someone should state the opposite so I had a reason to try this idea out. The custom types design went in the trash bin yesterday .