Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Freeing Algorithms

Reply
Thread Tools

Freeing Algorithms

 
 
Chris Uppal
Guest
Posts: n/a
 
      03-20-2006
Stefan Ram wrote:

[me:]
> > The third is also theoretical: it exposes a great deal of
> > detail about how the algorithm works, to the client code.

>
> This is true. But this exposure possibly can not be avoided.
>
> Software engineers often take hardware as a role model.
> Hardware devices have interfaces (connectors).


I think the hardware analogy is often pushed beyond its limits....


> So a device having a power-supply connector and a loudspeaker
> connector exposes that it needs power and possibly a
> loudspeaker. But hiding this might be impossible.
>
> It could add additional connectors in order to hide
> the information that it only needs a power-supply and
> a loudspeaker.


I suspect this is a rather misleading analogy. Well-designed and universal
hardware interfaces /do/ hide a lot of information. For instance, a mains plug
is the same shape whatever the power requirements (within limits) of the
appliance, so the mains "interface" is hiding a great deal of information.
That seems to me to be similar to the case where the interfaces used to define
requirements of an algorithm, or properties of an object, are defined very
broadly.

OTOH, if the hardware interface were as specific as in your example with Years,
then we would have something more like the mess with power adaptors for
laptops, phones, etc -- all of which seem to take malicious delight in strongly
coupling the laptop to the adaptor (you can't mix-and-match)

And there's the same tension in the design of hardware interfaces. The more
universal the interface (mains power) the more work the things that /use/ it
have to do. They have to convert the generic main power to their own specific
requirements, rather than just "assuming" that they'll get, say, 1.3 v
stabilised DC.


> > In your example it exposes the fact that it uses modular
> > arithmetic (which is probably acceptable), but it /also/
> > exposes the fact that it does /not/ use other arithmetic
> > operations. That increased coupling is (IMO) a very bad thing.
> > For instance, it restricts future improvements to the
> > algorithm.

>
> Within my paradigm, in this case, I will not /change/
> the existing algorithm, but /add/ another algorithm
> with the new interface.


But then you are pushing extra work onto the designers of the client objects.
They have to anticipate the interface required by the next algorithm, and
declare it. (That's assuming that the objects already have the necessary
abilities, but those are not exposed as an interface).

-- chris



 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      03-20-2006
"Chris Uppal" <(E-Mail Removed)-THIS.org> writes:
>But then you are pushing extra work onto the designers of the
>client objects. They have to anticipate the interface required
>by the next algorithm, and declare it.


This is assuming that an algorithm was /replaced/ by a
successor. My original paradigm was that algorithms and
interfaces do not change. So I thought about /adding/ an
/additional/ interface and algorithm that can be ignored by
clients (like Sun has added StringBuilder instead of changing
StringBuffer).

However, you might be right that in real live I /will/ change
interfaces and algorithms.


 
Reply With Quote
 
 
 
 
Oliver Wong
Guest
Posts: n/a
 
      03-21-2006

"Chris Uppal" <(E-Mail Removed)-THIS.org> wrote in message
news:441d7228$1$1167$(E-Mail Removed)...
> Stefan Ram wrote:
>
>> So there is no need to bind it to the special type »int« that
>> has many more features which are not needed here. The
>> following untested draft shows how the algorithm can be freed
>> from this binding.

>
> I can see what you are getting at, but I think there are several problems.
>
> The first is purely practical: it's hellishly verbose.
>
> The seconds is more theoretical: it requires the designer of the objects
> that
> the algorithm is applied to, to have considered these kinds of uses in
> advance.
> That means they have to decide what are sensible "bundles" of methods for
> algorithms to use, and to separate each bundle out into an interface.
> That way
> lies analysis paralysis. It's also a helluva lot of work for little gain.
>
> The third is also theoretical: it exposes a great deal of detail about how
> the
> algorithm works, to the client code. In your example it exposes the fact
> that
> it uses modular arithmetic (which is probably acceptable), but it /also/
> exposes the fact that it does /not/ use other arithmetic operations. That
> increased coupling is (IMO) a very bad thing. For instance, it restricts
> future improvements to the algorithm. Note that this is a kind of dual to
> my
> second objection, in that the coarser the bundles of methods "published"
> by the
> Year objects, the less closely coupled the algorithm is to the Years, but
> on
> the other hand, the greater the constraints on the design of the Year
> class.


On the topic of good OO design, the concept of a "year" and the concept
of an "integer" are not nescessarily interchangeable. Rather than passing in
some arbitrary integer into a method, and having that method answer the
query "If you take this integer, and interpret it as a Gregorian year
number, would this be a leap year in the Gregorian calendar?" it might be
better to have a type which defines a "point in time" (for simplicity, let's
assuming newtonian physics, and i.e. a globally agreed progression of time),
and then query that "point in time" object, does this point occur within a
leap year under the gregorian calendar?

The "point in time" might implement its state using ints representing
seconds since the unix epoch (and thus could represent points prior to the
epoch via negative numbers), or it might use BigInteger to represent
nanoseconds since the the Big Bang, or something else. It doesn't matter,
and you shouldn't need to know how it internally keeps track of its time.

Alternatively, you might have various Calendar objects, which take as
input a "point in time" object, and then could answer questions about that
point in time (e.g. there might exists calendars for which the concept of a
"leap year" is meaningless).

- Oliver

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
freeing memory Harald Kirsch Java 0 04-22-2005 09:17 AM
freeing memory Rajesh.Rapaka Java 17 04-21-2005 10:11 PM
Pix 501 VPN License Issue - Not freeing License Jens Haase Cisco 1 01-29-2004 08:29 PM
Freeing object created in JNI code? Gordon Beaton Java 1 10-27-2003 02:44 PM
freeing up hard drive space Stella Computer Support 2 10-07-2003 03:28 AM



Advertisments