Re: OOP/OOD Philosophy

> OOD only gives you a new way to orient your ideas, like there is a very
> different point of view betwen procedural and OO programming languages
> (supossing we don't use OO prog. languages only in a procedural way).
> Which is the best? Depends on your needs. (The best answer in
> computer-science worl is "depends on" :) )

Right; I'm not assuming that OO is the best tool out there. I work on
a large number of small projects, and for many of them procedural code
is just fine. However, I want to make sure I also understand the OO
mind-set. If it were just about using classes as the basic module and
enforcing data integrity through methods, then it's not a paradigm
shift; in fact, it's the realization of the procedural ideal. So to
me, there has to be a different way of viewing things.



> > But non-OOD is also design. Non-OOD focuses more on deriving the
> > algorithms, while OOD focuses more on the data, although the two
> > intersect. One can derive data from the algorithms/relations and vice
> > versa. So, given two different ways of doing something, and a former
> > way that is clearer and more direct, why use the latter? If it's an
> > issue of flexibility/re-usability, what's the thinking behind that?
> >
> Yes, you can design in any way. See the differences betwen a DFS in the
> "structured design" and an UML class diagram. Which is the best? Other
> time it depends.

Right, the question becomes this; what are the advantages of OO design
over non-OO design? Or at least, what are the trade-offs in each case?
The most obvious trade-off is directness. Non-OO design cuts straight
to the heart of the matter. However, does OO design offer something to
make up for its more vague and circuitous route?



[Cash Register Example]
> Yes, the problem isn't veru difficult, then why make a difficult
> solution? Why not create a simple CashRegister class with a "total"
> attribute and operation like: clear, add, sub, getTotal.

Because such a solution is essentially procedural, even if it uses
objects. In addition, it makes OO analysis pointless, because we would
have spent more time analyzing a problem, only to come to the same
solution that a more direct (predicate calculus) analysis would have
yielded; in addition, the predicate calculus analysis could have led to
the same object model. If we use the guidelines that data is private
and guarded by access methods along with the requisite guards then we
have most of that design. Grouping data and their operations together
is another general principle that can be used to get the rest of that
model. So in the end, we're looking at procedural analysis, along with
some code derivation guidelines to derive an object-based model. No OO
analysis there.


> > Right, which is what I'm seeing from both cases. An analysis of the
> > problem simply states relations and some of these relational statements
> > can't even be checked by code (take relations involving quantifications
> > over infinite sets or involving convenience functions that don't exist
> > in the implementation language). What differs here is what we are
> > solving. Are we solving the problem at hand, or do we choose to solve
> > a generalization one of whose instances is the problem at hand,
> > ostensibly for more flexibility?
> >
> Referent to the "infinite sets" want to say that some time ago a went to
> a class of funtional programming (I'm a nebie on this) and I like very
> much the way to approach to the problems. For example I can create a
> function that returns an infinite set of number and "connect" to a
> function that multiplies its values by 2. Is this functional program
> impossible to to in an OO language? No, it can be done in a different
> way, that the difference.

Functional languages can support infinity through lazy evaluation,
however this support is limited. They generate the values on an
as-needed basis -- but this doesn't fulfill the needs of quantification
over infinite sets, which requires evaluation of the entire infinite
set -- an impossible concept, but one that is useful as an analysis
tool. For example, if I quantify:

(All x such that x in Integer and Odd(x) = True)

Assuming the mathematical definition of Integer (and not the computer
limited one) this requires evaluation of each element of an infinite
set. This is something that can never be implemented on a computer,
but it is a useful analysis tool for the user.

[Radar Example]
Ok, I think I see what you're doing. You have a series of algorithms
(or objects) that feed their output into other algorithms/objects,
hence the pipeline. The outputs and inputs are objects, and I assume
you are using polymorphism in order to supply a unified interface?
This also means you could build a collection of the algorithms you want
for a given task and customize processing chains by supplying these
collections when needed, and deriving new ones to introduce new
processing functionality?


Thanks.

.

Relevant Pages

  • Re: high level languages for synthesis
    ... languages are more distinct from their cycle-accurate cousins than ... straightforward to use a spiral design methodology using VHDL, ... implement a wide variety of other scientific algorithms. ... FPGA-targeting C-syntax HLL is somehow inherently sequential. ...
    (comp.arch.fpga)
  • Efficient algorithms for number systems
    ... English, Traditional Welsh, Japanese and French ... I don't know how to design algorithms for non-English languages ...
    (comp.programming)
  • Re: Speculative Design Hypothesis (with predictions) 2nd draft
    ... languages are human products, but that does not make them "designed". ... natural languages has nothing to do with design. ... wings and echolocation. ... Because the genetics and fossil evidence show otherwise. ...
    (talk.origins)
  • Re: Overview Of New Intel Core i7(Nehalem) Processor
    ... people settled down and started doing more disciplined design. ... apps will still need mathematical, disciplined, unambiguous languages. ... See, tha tis wha tI mean, yo udo not knwo C, and yet yo uhave more opinions ... I wrote my first EPROM programmer with zeros and ones in machine code, ...
    (sci.electronics.design)
  • Re: Speculative Design Hypothesis (with predictions) 2nd draft
    ... languages are human products, but that does not make them "designed". ... natural languages has nothing to do with design. ... evidence to point to them not being human. ... wings and echolocation. ...
    (talk.origins)