Re: input stream 101

blmblm@xxxxxxxxxxxxx wrote:
....
> So, the reason for having a separate interface definition is to have
> something short that just lists method signatures? Well, okay.
> I still think it's a bit redundant to have both an interface and
> a class, though perhaps there's an additional benefit I'm not
> thinking of.

Keep in mind that, for me, this is a chance to experiment. The idea
of:

Foo fooBar;
fooBar = new Bar();

I've scratched the surface with non-generics collections and that idea
seems to be the best way to use them, like referring to an ArrayList as
a List (if I have that right).

Partly it's just to apply that idea and see what happens, I think
you've shot down all my other reasons ;)

> With regard to documentation, do you know about the "javadoc"
> tool? (I think you're using CLI tools; if you're using an IDE,
> such as Eclipse, there's probably equivalent functionality in
> it somewhere.) This is something that takes your code (and its
> comments) and produces HTML-form documentation similar to the Java
> documentation you find at Sun's Web site and elsewhere. In fact,
> if you take completely uncommented code and just run it through
> javadoc (e.g., "javadoc MyProgram.java"), you'll get *something*,
> and it's even something that serves pretty much your purpose for
> having an interface, I think. Well worth knowing about if you're
> going to do much Java-writing. (I know -- so much that's "well
> worth knowing about", so little time .... )

I knew about javadoc and have seen code commented with it. It seemed
to make the code so ugly, my opinion, that I couldn't justify that.
However, it's interesting to know that undocumented code can be run
through javadoc, that's neat.

I think I'll have to start doing some documentation, it, err "seemed"
"faster" to not deal with that...I know that's erroneous thinking, but
there you are.

...
> But the methods defined in Test16 are exactly the same as those in
> BasicTidy, except that Test16 also has a constructor. How is the
> interface simpler? Why not just have a class BasicTidy? (You might
> still be right that you want the separate interface; I'm just trying
> to point out alternatives.)

Well, when I started the BasicTidy interface the idea was that it would
just have setUrl and setFileName as methods. It's not intentional that
there's a 1-to-1 with Test16. BasicTidy was supposed to be
smaller/subset of Test16.

Yes, Test16 is a crappy name, I kept it largely because I just wanted
to use it as someone elses code and not muck with it. I believe that
it now makes sense to go back, get rid of the BasicTidy interface and
rename Test16 to BasicTidy.

I'm not sure I would've arrived there without the input here, because,
err, "it's my code and therefore it's perfect and doesn't need
changing"; that kind of thinking. It's good to see what others think
of what I have, definitely :)

....
> Sure .... I'm not sure I'm 100% clear where you're going with this
> (you may not be either), but the idea of separating the creating
> and manipulating of a Tidy object from the user interface seems like
> a fine idea, since then it's easy to use the same back end with
> different front ends (CLI, GUI, etc.).

Where I'm going with this is that I have more than 100 HTML files on my
hard drive. I want to take those files, tidy-ize them, extract some
XML, use XSLT to insert (?correct term?) that data into a database,
probably MySQL. All the HTML files are the same pattern.

What I have right now is the capability to hard-code in the URL for one
of these HTML files and tidy-ize it. I want to just stick with this
one file, for now. The entire process is:

1.) hard code url
2.) run black box (java -jar ControlTidy.jar)
3.) get foo.html
4.) extract xml from foo.html for foo.xml
5.) put foo.xml into, for examply, MySQL

I could work more on the front end, like a nice GUI, but I'd rather get
some output. To that end I've been looking into some stuff. I'm not
at home, so I don't have the links, but I looked at some sample code at
sun that simply copies xxx.txt to yyy.txt, named FileCopy.

(My time on this computer is expiring, so I can't look it up right now.
It uses like FileReader, if memory serves. I was thinking of using
that in conjunction with ByteStreamReader to read something directly
off the hard drive.)

I'm more interested in the back-end, though. gotta go!




> (By the way, I'm not sure that if I were designing this stuff from
> the ground up I'd bother with using threads here. I'm guessing you
> do because you adapted the code from something that uses threads.
> Not a problem, just something to keep in mind if you continue
> refining the program. Also, if BasicTidy extends Runnable -- which
> I'm not sure makes object-oriented-design sense, but whatever -- then
> there's no need for it to explicitly include a signature for run().
> I'm not really sure whether the duplication could be harmful.
> Maybe someone else is following this and can help with that.)
>


I'd like to get rid of that, it seems out of place.



-Thufir

.

Relevant Pages

  • Re: input stream 101
    ... Why do you want this interface BasicTidy? ... >BasicTidy implements Runnable and Test16 implements BasicTidy. ... if class ControlTidy extends Tidy and implements Runnable ...
    (comp.lang.java.help)
  • Re: input stream 101
    ... >I do want to create my own interface, BasicTidy ... >I do want ControlTidy to call methods on an object which is of type ... Why do you want this interface BasicTidy? ... if class ControlTidy extends Tidy and implements Runnable ...
    (comp.lang.java.help)
  • Re: input stream 101
    ... Why do you want this interface BasicTidy? ... if class ControlTidy extends Tidy and implements Runnable ... [thufir@arrakis tidyXhtml]$ date ...
    (comp.lang.java.help)
  • Re: input stream 101
    ... If you want something with a GUI for those ... I do want to create my own interface, BasicTidy ... I do want ControlTidy to call methods on an object which is of type ...
    (comp.lang.java.help)