Hi Daniel, I am not sure that there is any right answer. If you want to see examples, you can look how I did it in NeoCSV, NeoJSON or STON. They are all similar, but there are small differences.
You should do what feels best to you. Object design is (much more) about messaging that about class hierarchies. If some object understands the messages that another object wants to send it, then is compatible, independent of class hierarchy. It only makes sense to subclass if you gain something, like an implementation and if the superclass was designed to be subclasses. Often you can just implement a couple of messages (say, a small part of the stream protocol) and your object can be used (say, pass as a stream). It also makes sense to reuse message selectors for similar behaviour. Most of my parsers understand #next, #atEnd, #close, #upToEnd - it helps other to immediately understand what you mean. HTH, Sven > On 18 Jan 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 > > > >
