Re: Whose Fish?

On May 11, 8:10 am, Jordan Marr <jnm...@xxxxxxxxxxx> wrote:
In my mind there are two issues that I have problems with. The first
one is where someone is trying to convert a 'logic' problem to an OO
one. I have an issue with this because to me, logic is not
condusive to facilitating object oriented conceptualising which as far
as I am concerned requires a great deal of fuzzyness.

To me, logic will always equate to procedural thinking (and should not
be equated to being a bad thing - it is, in its place a good thing).
But I will say that to me an object may contain logic parts and in
that regard one could also say that an object may contain procedural
parts, but that does not mean to me that objects are always logical
entities.

Andy,
In fact, all software applications have logic. They all have user
input, some sort of logic processing on the input, and finally some
sort of output, to the screen, printer, network, db, or somewhere. An
OO software without any logic would simple be a abstracted model of
the problem domain that didn't do anything!

I have noticed over the years that some people require contextual
detail when doing OO and some people don't. I wonder if that culture
defines whether someone does OO following rigerous methods and
techniques (OO Principles) or if they just go with the flow so to
speak. i.e. does the 'context' of ones culture (whether they are
naturally high or low context people) affect the way people approach
OO.

I think that people who are not good at abstracting problems will
definitely be more productive writing strictly procedural code.

This sounds like yet another "you hate OO because you don't get OO"
insult. To me, OO is a *lower* level of abstraction than p/r because
it uses objects pointing to objects instead of relational rigor to
define most of the relationships between things. OO is like the Go To
of modeling: a wad of pointers. Good p/r also tends to meta-tize
things that OO'ers like to hard-wire into code. I've demonstrated this
already with my Payroll code example versus R. Martin's. How is hard-
wiring a higher abstraction? OO has no definable, dissectable,
analyzable rigor. If there is a genius to it, nobody has been able to
isolate it in a western-reductionalist style, instead sounding like a
bad episode of Kung fOO. (I am not saying traditional Eastern
thinking is necessarily bad, just that it is harder to dissect and
test in a reproducable, measurable, and scientific way. Maybe fuzzy
Zen thinking works better, but it eludes dissection.)

Of
course they will have to master OO techniques only enough to
understand how to utilize the OO framework tools that are already in
place to help them. Those reusable framework tools are of course
created by abstract thinkers who intended to create a generic tool to
solve many peoples' problems, instead of the immediate issue at hand.

You still haven't demonstrated with code that OO automatically leads
to more reuse or better biz frameworks.


The second issue more directly relates the problem being solved to the
solution provided. That is, to me this type of problem (logic
problems) are usually solved by some form of mathematical equation.
I think that in software development I have always referred to these
types of equations as 'algorithms' which are usually I think
implemented in a single high level function call (often to a bunch of
smaller detailed function calls). Given this, I cant say how one
could claim to have developed an object oriented solution when
implementing a single algorithm when the whole meta structure of
executing an algorigm is nothing more (to me) than the procedural
implementation of a logical set of steps (calculations).

It is all in how you percieve the problem domain and how you choose to
model it.

So we *are* modeling our view of the world instead of modeling the
world? That can lead to a lot of bias because people will give a
better score to techniques that better model their internal world, not
necessarily those that are objectively better. I am sure Seung-Hui
Cho's mental model is different than Mary Poppin's.


I think
one could say they have used object oriented techniques to solve the
problem (such as encapsulation, polymorphism and abstraction), but I
dont think one should suggest that the result is in its nature object
oriented, as I do not see an algorithm as being 'oriented towards
objects' (its more oriented towards being a service) since it can be
executed as a function/method call which to me at best perhaps is
merely part of an object.

Modelling the problem domain into software objects is IMO an OO
solution.

"IMO", that's the problem. You have to SHOW, not TELL. You have to
show how OO better fits the actual real world. And what about things
based on intellectual property or capital, like money? They are not
physical. Yes, you can model money transactions as a bunch of
mechanical hands moving coins around, but most would agree that is a
clumsy way to go about it. Sometimes the real world is F'd such that
we *don't* want to recreate it. Few miss library card catalogs, and
you would get fired if you emulated them if charged with building an
online book search. The purpose of biz computers is to make business
more efficient, not necessarily copy physical versions of the
activities.


Jordan

-T-

.

Relevant Pages

  • Re: Whose Fish?
    ... techniques or if they just go with the flow so to ... I think that people who are not good at abstracting problems will ... Those reusable framework tools are of course ... as I do not see an algorithm as being 'oriented towards ...
    (comp.object)
  • Re: Havent done anything real with OOP yet.
    ... But it is an algorithm description and, ... simulation needs. ... hardware to/from the network port. ... driving the abstraction of a rather specialized chunk of hardware. ...
    (comp.object)
  • Re: How do you bitwise operations in Ada 83 and 95
    ... desire to use a low level abstraction to access the bits. ... Here you will note that the algorithm is the same as the ... The bit-wise operations in the nsieve function ...
    (comp.lang.ada)
  • Re: Creating an operating system
    ... Richard Harter wrote: ... >>of abstraction in the war story which you snipped ... A program, any program, can be regarded as an algorithm ... for this next level of abstraction. ...
    (comp.programming)
  • Re: Creating an operating system
    ... Richard Harter wrote: ... >>of abstraction in the war story which you snipped ... A program, any program, can be regarded as an algorithm ... for this next level of abstraction. ...
    (comp.os.linux.development.system)