Re: Should this be an object?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
news:eqktRIatHHA.4232@xxxxxxxxxxxxxxxxxxxxxxx

"MP" <Nospam@xxxxxxxxxx> wrote in message
news:467c0388$0$3575$ae4e5890@xxxxxxxxxxxxxxxxxxxxxx
<snipped>

as you can see I'm still quite confused on all this...but really, I am
trying to understand.. <g> .... maybe just not successful :-)


To paraphrase Stroustrup, poorly... <g>
Objects (classes) exist to help a programmer organize his code more
logically. To make it easier to avoid mistakes and to help him find and
repair mistakes if a mistake is made. Period.

An object-oriented program is simply one that is build up from the
colaboration of various types of objects through well-defined interfaces.
There are no specific rules as to how these interfaces should be used, or
even what the interfaces should look like. The only rule is that they
should
provide some logical services which simplifies one's understanding of the
solution and makes it easier to maintain. To that end, a whole range of
mechanisms are at one's disposal - Abstraction, encapsulation,
polymorphism,
hierarchies, etc.

On the other hand, sometimes an object isn't needed to provide a solution.
Sometimes everything a process needs is right at hand and fully
understandable in place. In that case no amount of encapsulation,
abstraction, polymorphism, ... is going to improve anything. (Quite the
opposite usually.)

Usually the decision of whether to use an object or not, or what kind of
services to support if an object is choosen, is totally dependent on
service
requirements outside the mechanics of OO. Anything from how many may be
needed to how often you may need to revisit will likely impact your
decision. One commonly has to adopt a holistic view.

Your so called "unsuccessful" solution may be ideal in one case, and
dismal
in another. To know the difference - trust your instincts. If something
feels silly or awkward - it is usually silly or awkward. If something
seems
right - it is probably a good working solution. Let the problem be your
guide to developing a solution. Don't try and force a solution on a
problem.
Or make a problem out of a solution. <g>

hth
-ralph



Thanks to all for your inputs.
Mark
:-)


.

Relevant Pages

  • Re: Should this be an object?
    ... Objects exist to help a programmer organize his code more ... repair mistakes if a mistake is made. ... colaboration of various types of objects through well-defined interfaces. ... mechanisms are at one's disposal - Abstraction, encapsulation, polymorphism, ...
    (microsoft.public.vb.general.discussion)
  • Re: Delphi makes it to digg!
    ... so many times from Steve McConnell's books. ... I see today the programmer rather like a doctor, curator, social assistant in helping the user in his pains rather than a mathematician in his cubicle trying to implement a certain algorithm dictated by theory. ... About 'waterfall thinking' -> 'take a few steps and revisit': ... same mistakes, though you clearly identify them and as a team declare ...
    (borland.public.delphi.non-technical)
  • Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
    ... And we do make plenty of mistakes. ... And when we fix them, we have to maintain bug-compatibility to allow live migration from the broken version to the good version. ... In my experience hardware is a lot less sloppy than software. ... shiny interfaces will have bugs and problems. ...
    (Linux-Kernel)
  • Re: VARY too many devices offline
    ... How would you handle a person that scrutinizes blood for a living and mistakes a diagnosis? ... Its possible that a programmer could write a program that misdiagnoses a test result and yes that could lead to the persons death, but presumably there are other fingers in the stew to catch the errors. ... I would suggest an incorrect VARY command might cause some amount of grief but not enough get fired over. ... That is almost as bad as saying your fired as you don't trust your operators so I am going to attempt to intercept commands and double check them. ...
    (bit.listserv.ibm-main)
  • Re: Poll : do you do peer reviews / code reviews / design reviews
    ... A bug is a bug ... of code -- assume the programmer is competent (else why did you ... If you document interfaces, someone else can put together test ... This impacts the way you design your system -- since you want ...
    (comp.arch.embedded)