Re: Should this be an object?


"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


.

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. ... feels silly or awkward - it is usually silly or awkward. ...
    (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: 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: Question about fair wage for a machine operator.
    ... Not a programmer or a machinist, but a sharp ... fellow who is always at work on time, makes few mistakes and can be ...
    (alt.machines.cnc)
  • Re: [Lit.] Buffer overruns
    ... they can "start writing bug-free code straight away"! ... The programmer should take responsibility for the code he writes, ... should document his interfaces, ...
    (sci.crypt)