|
You wrote: problem i guess was not related to the design. it was the inability of the developers to convert the design into programs in java that was the problem. Our design strategy was the following - 1. Design templates for frames, comboboxes, tables and other objects. The templates were to be inherited by the calling programs. All general bits of code was encapsulated in the templates. Abstract methods for painting the screen, filling the database,validations etc.. were defined. Developers are given these templates with documentation before they start coding. Our problem starts from there. Work not getting completed and programmers going into endless loops of error detection and correction starts. I have to mention here that we had an all freshers team. This could be a design problem. Usually, I have found it an advantage to have objects like combo boxes "contained" in larger objects. I do not see any mention of objects relating to your business. I do not want any confidential information revealed, and perhaps this is why you didn't mention anything about that, but this concerns me. If you do not have objects that describe your business or business process or at least this application, you very likely have a design problem. If you have a "street address object" that "inherits" from a combo box, then you have a design problem. This means you have not correctly described what object oriented theory calls "is a" and "contains" relationships. Some texts will use terms like "inherits from" and "uses" but it is the same issue. I mention this because your examples seem to be about the internals of a program and not the externals of your business. Inheritance is not a clever programming trick. It's real power comes from its ability to represent the reality outside the program. You may also have simply overdone it. This is no defect in theory, or even of design, but of pragmatics. If every combobox and every label has its own object, even validly in the theory, you have probably defined your objects too finely. In truth, many of these will relate very strongly to the application (the Frame object) that they are defined for. Reuse will be impossible. In this case, they should not be separate objects. Reducing these kinds of objects, if you have them, will not hurt your object-orientation and will speed debug. Keep in mind I have the handicap of not seeing real code. Thank you for listening to my thoughts. Good luck. Larry W. Loen - Senior Linux, Java, and iSeries Performance Analyst Dept HP4, Rochester MN
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.