× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.