Thanks to all of you for the advice! > On Jan 18, 2015, at 9:31 AM, Johan Fabry <jfa...@dcc.uchile.cl> wrote: > > Hi Daniel, > > I have disclaimers as the 2 previous responses, this is my feeling about the > matter. :-) > > I would prefer to think purely in terms of the API that you want to use when > reading the file, and have that clear and explicit. So do NOT subclass Stream > nor do a class extension with #nextFoo. I would think in terms of the Stream > API when doing that, and reuse as many message names as possible, because it > is a fairly ‘standard’ API. So: option 1, without the use of > doesNotUnderstand. > >> On Jan 18, 2015, at 06:11, Daniel Lyons <fus...@storytotell.org> wrote: >> >> This is an OO design question. >> >> For my task, I have some objects and a particular file format that encodes >> them. I want to be able to read the file and create those objects. The >> Stream API seems like the right way to do this, but I'm not sure how to >> encapsulate my code. I see these options: >> >> • Create a new class (subclass of Object) that implements #next to return >> the next object in some underlying stream. >> >> Pro: very simple, one place with all the code. Con: what about the rest of >> the Stream and/or Collection APIs? Is it wise to delegate everything else to >> the underlying stream with #doesNotUnderstand:? >> >> • Create a new class, subclass of Stream, that implements #next like the >> above. >> >> Pro: still pretty simple, not sure what is needed to implement the API >> completely (I did add a method #atEnd). Con: not sure if more methods are >> missing; unclear about initialization (overrode class>>#on: to call >> #basicNew). This seems close to the right approach but I'm unsure. >> >> • Create a method #nextFoo on the existing Stream class. >> >> Pro: very simple—no new class. Con: nextFoo doesn't integrate well with the >> rest of the API (#do: for instance), not sure this is clean or wise. >> >> • Ignore the Stream classes altogether. >> >> Pro: No chance of misundestanding. :) Con: everything else. >> >> Advice? >> >> Thanks for your time, >> >> — >> Daniel Lyons >> >> >> >> >> > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >
— Daniel Lyons
