Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

A method from one class is substitued for that in another class

 
Steven Zoraster
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have what I thought were 2 completely different class.

One is named Grid and the other is named DataReaderWriter.

DataReaderWriter include methods that among other things
reads data from disk.

I have software I that calls a Grid method which should
import already read data into a Grid object,
but instead calls the DataReaderWriter method the reads
data. Very strange. Does anyone have an idea about what causes
this problem and what to do about it?

In summary, I call one method from one class and end up in
a relate but different method in another class
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34178
340
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steven,
Welcome to CodeRanch! That could happen if one class subclasses another depending on how you are calling it.

Can you show some code? In fact the act of simplifying your code so you can post a small example may give you a hint.
 
Steven Zoraster
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne Boyarsky wrote:Steven,
Welcome to CodeRanch! That could happen if one class subclasses another depending on how you are calling it.

Can you show some code? In fact the act of simplifying your code so you can post a small example may give you a hint.


-------------------------------------------------------------------------------------
Jeanne. The Grid class and the DataReaderWriter class are as far as I know independent. As is the Faults class which
provides the data to the Grid class (Sorry about how confusing this is.)

Here is the Grid method call:


public boolean imposeFaults(Faults Fin) {...)

Where F is a class containing the data which
is first read from disk as double [][];

But after calling impose Faults() I find myself in
the DataReaderWriter() method:
public double [][] readFaults(String fileName) {..}

where fileName is the name of the
disk file where the data is stored. Yes
DataReaderWriter "knows" fileName but why
I jump into that method I not know.

So in some sense there are 3 classes involved
but up until yesterday they were independent!

Important but not previously mentioned is
that this same sequence, read data, put it
in a Faults object and then call Grid.imposeFault(Faults F)
is done in other software I have developed where
it still works! So, it is something about the
new code which I can not publish here without
giving away trade secrets.

Steven
 
Jayesh A Lalwani
Rancher
Posts: 2756
32
Eclipse IDE Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steven,

You know, most java developers can read java better than they can read English. It would be much more helpful if you post the code for all the 3 classes. You can remove the code that is not relevant to the issue at hand.
 
Steven Zoraster
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jayesh A Lalwani wrote:Steven,

You know, most java developers can read java better than they can read English. It would be much more helpful if you post the code for all the 3 classes. You can remove the code that is not relevant to the issue at hand.


Well, I am going to throw more words at it.
(The code part is highlighted below.)

I start reading 2-d fault data from disk. One
data triple (x y id) per record. (In an ASCII file
that can be read in Windows Notepad.)

I have a DataReaderWriter Class a Grid Class and
a Fault Class.

Assume the disk file name for the faults is .\fault.txt


Compressed the troublesome code looks like:



and after the G.imposeFaults(F) in the
debugger in Netbeans, I am suddenly
back in double [][] fff = DD.readFaults(.\fault.txt);

where DD has "remembered" the file
name correctly. And is loading the
faults from disk into some array
somewhere in memory...

I can not show any of
the internal working of G or F
with giving away commercial secrets.
The relevant (?) part of DD is given below.

Today I am a little less upset about
than I was yesterday, because I have
found that the rest of the code runs
successfully. So I can keep programming.
But, there is something fundamentally
wrong here....

Steven


>
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic