I have a Location
class which represents a location somewhere in a stream. (The class isn't coupled to any specific stream.) The location informat开发者_运维知识库ion will be used to match tokens to location in the input in my parser, to allow for nicer error reporting to the user.
I want to add location tracking to a TextReader
instance. This way, while reading tokens, I can grab the location (which is updated by the TextReader
as data is read) and give it to the token during the tokenization process.
I am looking for a good approach on accomplishing this goal. I have come up with several designs.
Manual location tracking
Every time I need to read from the TextReader
, I call AdvanceString
on the Location
object of the tokenizer with the data read.
Advantages
- Very simple.
- No class bloat.
- No need to rewrite the
TextReader
methods.
Disadvantages
- Couples location tracking logic to tokenization process.
- Easy to forget to track something (though unit testing helps with this).
- Bloats existing code.
Plain TextReader
wrapper
Create a LocatedTextReaderWrapper
class which surrounds each method call, tracking a Location
property. Example:
public class LocatedTextReaderWrapper : TextReader {
private TextReader source;
public Location Location {
get;
set;
}
public LocatedTextReaderWrapper(TextReader source) :
this(source, new Location()) {
}
public LocatedTextReaderWrapper(TextReader source, Location location) {
this.Location = location;
this.source = source;
}
public override int Read(char[] buffer, int index, int count) {
int ret = this.source.Read(buffer, index, count);
if(ret >= 0) {
this.location.AdvanceString(string.Concat(buffer.Skip(index).Take(count)));
}
return ret;
}
// etc.
}
Advantages
- Tokenization doesn't know about Location tracking.
Disadvantages
- User needs to create and dispose a
LocatedTextReaderWrapper
instance, in addition to theirTextReader
instance. - Doesn't allow different types of tracking or different location trackers to be added without layers of wrappers.
Event-based TextReader
wrapper
Like LocatedTextReaderWrapper
, but decouples it from the Location
object raising an event whenever data is read.
Advantages
- Can be reused for other types of tracking.
- Tokenization doesn't know about Location tracking or other tracking.
- Can have multiple, independent
Location
objects (or other methods of tracking) tracking at once.
Disadvantages
- Requires boilerplate code to enable location tracking.
- User needs to create and dispose the wrapper instance, in addition to their
TextReader
instance.
Aspect-orientated approach
Use AOP to perform like the event-based wrapper approach.
Advantages
- Can be reused for other types of tracking.
- Tokenization doesn't know about Location tracking or other tracking.
- No need to rewrite the
TextReader
methods.
Disadvantages
- Requires external dependencies, which I want to avoid.
I am looking for the best approach in my situation. I would like to:
- Not bloat the tokenizer methods with location tracking.
- Not require heavy initialization in user code.
- Not have any/much boilerplate/duplicated code.
- (Perhaps) not couple the
TextReader
with theLocation
class.
Any insight into this problem and possible solutions or adjustments are welcome. Thanks!
(For those who want a specific question: What is the best way to wrap the functionality of a TextReader
?)
I have implemented the "Plain TextReader
wrapper" and "Event-based TextReader
wrapper" approaches and am displeased with both, for reasons mentioned in their disadvantages.
I agree that creating a wrapper that implements TextReader
, delegates the implementation to the underlying TextReader
and adds some additional support for tracking of location is a good approach. You can think of this as the Decorator pattern, because you're decorating the TextReader
class with some additional functionality.
Better wrapping: You can write it in a simpler way to decouple your TextReader
from the Location
type - this way you can easily modify Location
independently or even provide other features that are based on tracking the progress of reading.
interface ITracker {
void AdvanceString(string s);
}
class TrackingReader : TextReader {
private TextReader source;
private ITracker tracker;
public TrackingReader(TextReader source, ITracker tracker) {
this.source = source;
this.tracker = tracker;
}
public override int Read(char[] buffer, int index, int count) {
int res = base.Read(buffer, index, count);
tracker.AdvanceString(buffer.Skip(index).Take(res);
return res;
}
}
I would also encapsulate creation of the tracker into some factory method (so that you have a single place in the application that deals with construction). Note that you can use this simple desing to create a TextReader
that reports the progress to multiple Location
objects too:
static TextReader CreateReader(TextReader source, params ITracker[] trackers) {
return trackers.Aggregate(source, (reader, tracker) =>
new TrackingReader(reader, tracker));
}
This creates a chain of TrackingReader objects and each of the object is reporting the progress of reading to one of the trackers passed as arguments.
Regarding Event-based: I think that using standard .NET/C# events for this kind of thing isn't done as frequently in the .NET libraries, but I think this approach may be quite interesting too - especially in C# 3 where you can use features like lambda expressions or even Reactive Framework.
Simple use doesn't add that much boiler plate:
using(ReaderWithEvents reader = new ReaderWithEvents(source)) {
reader.Advance += str => loc.AdvanceString(str);
// ..
}
However, you could also use Reactive Extensions to process the events. To count the number of new lines in the source text, you could write something like this:
var res =
(from e in Observable.FromEvent(reader, "Advance")
select e.Count(ch => ch == '\n')).Scan(0, (sum, current) => sum + current);
This would give you an event res
that fires each time you read some string from the TextReader
and the value carried by the event would be the current number of line (in the text).
I would go for the plain TextReader
wrapper, because it seems the most natural approach. Also, I don't think the disadvantages you mentioned are really disadvantages :
- User needs to create and dispose a LocatedTextReaderWrapper instance, in addition to their TextReader instance.
Well, if the user needs tracking, he will need to manipulate tracking-related objects anyway, and creating a wrapper isn't such a big deal... To make things easier, you could create an extension method that creates a tracking wrapper for any TextReader
.
- Doesn't allow different types of tracking or different location trackers to be added without layers of wrappers.
You could always use a collection of Location
objects, rather than a single one :
public class LocatedTextReaderWrapper : TextReader {
private TextReader source;
public IList<Location> Locations {
get;
private set;
}
public LocatedTextReaderWrapper(TextReader source, params Location[] locations) {
this.Locations = new List<Location>(locations);
this.source = source;
}
public override int Read(char[] buffer, int index, int count) {
int ret = this.source.Read(buffer, index, count);
if(ret >= 0) {
var s = string.Concat(buffer.Skip(index).Take(count));
foreach(Location loc in this.Locations)
{
loc.AdvanceString(s);
}
}
return ret;
}
// etc.
}
AFAIK, if you use PostSharp, it injects itself into the compiling process and rewrites code as necessary so you don't have any eternal dependencies to ship (other than requiring API users to have PostSharp to compile your source).
精彩评论