>
> Now that we're stuck with structure%component, but the "component"
> thing-o
> can actually be a function, we're halfway there. We don't yet have
> type-
> bound updaters. So, instead of writing "structure%component", what
> you should really do is write a function named
> "get_component(structure)"
> and a subroutine named "store_component(structure)" and clench your
> teeth
> and use the function and subroutine everywhere to access the
> abstraction --
> just in case you might discover some time later that you need to change
> its representation. At least that's what Parnas recommended in 1972,
> and
> what Computer Science professors have been teaching ever since.
>
> So the % choice is irrelevant. You should see it in exactly two places
> for each component: The reference function and the store subroutine,
> each
> having one executable statement.
I have just spent 2 weeks rewriting about 1500 lines of legacy fortran.
It was unavoidable, because it was poorly structured, and I needed to
be able to access the code in a slightly different way than what was
originally intended.
I am also an OO advocate, and write in several languages other than
fortran regularly, such as python and objective-C (the latter being a
smalltalk-c mix). When I write in OO languages, I always use
'accessors', which are the set and get methods you refer to.
For many years I also used this approach in Fortran 90. I wanted it to
be more OO. But lately I've begun to question whether it is really
worth all the trouble in Fortran.
For example, my 1500 lines of fortran 77 quickly became 2500 lines of
fortran 90, due to structuring of data and explicit typing, even
without accessor methods. Luckily I found many cases of duplicated
functionality which I could remove, meaning the fortran 90 was only a
little longer than the f77. If I had added accessor methods, I think
there would have been another 500 lines at least, and the code would
have been slower.
It is not easy to justify to skeptical fortran 77 programmers that
their 1000 line program has become 2000 lines in fortran 90, and runs
more slowly to boot!
So, as much as I think data hiding is important, and useful in other
languages, I have my doubts about fortran.
Drew McCormack
|