I think you will be happiest in the long run if Tree exposes an interface
that is the same as other interfaces you are familiar with, and it is
entirely reasonable for a Node object to 1) exist and 2) know its own path.
Also I think a "copy" method should only copy, not "copy and instantiate"
(if a function is most accurately described with a phrase containing 'and',
it wants to be at least two functions). Keeping its responsibilities small
will make it easier to write, test, and maintain.
There's something pulling at my brain about this class structure that I
can't quite identify without seeing the data, but it is something about the
name and responsibilities of Tree. Knowing how to copy is treelike. But
knowing how to deal with specific metadata types is possibly more Nodelike?
You say there are lots of possible input types and output types -- what
does the part between them look like? Does everything go through some sort
of common state? If so, it would make sense for a Node to know how to
transform between its content type and that common form, and for Trees to
deal only with the common form. Admittedly I cannot imagine what that
common form would look like. But otherwise you're writing a fully-connected
graph of transforms between everything and everything and you will be
extremely sad as this graph grows.
Anyway. I'm not quite sure where I'm going with this, without having the
code in front of me. But I think it's worth being very explicit with
yourself about what you expect the responsibilities of each class to be,
because then you can look at whether those responsibilities make sense,
whether the class names correctly describe those sets of responsibilities,
and what interfaces you need to expose to make it harmonize.
On Tue, Nov 10, 2020 at 4:34 PM McDonald, Stephen <[log in to unmask]>
wrote:
> Fellow library code wranglers,
>
> Coding questions don't come up often here, but I think this might be the
> best group to ask, as my question somewhat involves both coding and the
> nature of metadata and data. A considerable amount of my work involves
> ingesting materials into our institutional repository. We get this
> material from many sources in many formats; PDF, Quicktime, WAV, etc., with
> metadata in XML, MARC21, or even spreadsheets. It might be organized as
> filesystem directories, zip files, or images with imbedded metadata.
> Before loading into the repository, the metadata must be extracted and
> transformed, and the data files reorganized for convenient ingest.
>
> To make this easier, we have written a toolkit (in Ruby) which handles the
> conversion. You select the source type (e.g. zipfile of electronic theses
> from Proquest), specify the directory/zipfile/whatever containing the data,
> and the toolkit executes all the transforms and organizes into a convenient
> directory structure, ready to ingest into the repository. The problem is
> that the code in the toolkit is clunky, making it difficult to add new
> sources and the needed transformations.
>
> I am rewriting the toolkit from scratch, with a modular design. I want a
> consistent set of methods defined in an abstract class for a package of
> data (which I am calling a Tree), with subclasses defining the exact
> behavior of the methods for directories, zipfiles, images with imbedded
> metadata, etc. I'm sure this is familiar to some of you. A file or
> directory (or analog) within a Tree is defined as a path from the root of
> the Tree
>
> The question I have is the best model to use for the arguments of the
> methods of this class. For instance, I want an analog to the copy method,
> to copy a file from the input Tree to the new ingest Tree. The ruby
> filesystem copy method is .cp(src, dest). An analog method would have to
> specify the input Tree along with the input path, and the output Tree plus
> the output path. So I could define the method as Tree.cp(srctree, srcpath,
> desttree, destpath). Or I could go a little more abstract and define a
> class Node which is a combination of a Tree and a path. Then I could
> create Tree.cp(srcnode, destnode), which looks more like the familiar
> filesystem methods.
>
> Does anyone have an opinion on which would be better? Using Nodes looks a
> lot cleaner and appeals to my sense of organization. I will be defining a
> Tree.glob method, so that should handle instantiating source Nodes, but
> output Nodes would need to be instantiated. The first method avoids the
> complication of instantiating Nodes before using them in copy and move
> commands. I'm not sure which would be easier for writing specific ingest
> routines for a new data source, since someday someone else will have to
> write them. Any thoughts?
>
>
> Steve McDonald
>
> [log in to unmask]<mailto:[log in to unmask]>
>
--
Andromeda Yelton
Web Applications Developer, Berkman Klein Center: https://cyber.harvard.edu
Lecturer, San José State University iSchool
http://andromedayelton.com
@ThatAndromeda <http://twitter.com/ThatAndromeda>
|