Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualEctara

Posted 20 April 2013 - 11:43 AM

You rule out components, but I'm not sure why (you could potentially have a "reading" component, a "writing" component, a "rewinding" component, etc.)

 

since they both operate upon a common state, so composition would be out, since having two separate states would break the functionality.

Composition wouldn't be feasible, because the reading and writing depend upon a single offset within the file. In order to do this, the components would have to know about the base stream class' member variables, and interact with them, in order to manipulate a shared state. It seems like this is counter-intuitive, and that it would make more sense if the higher order classes were derived classes, since all of InputStream, OutputStream, and RewindableStream have an is-a relationship with BasicStream.

 

 

What you're trying to do violates the Liskov Substitution Principle.

I can't quite see how that is so. An InputOutputStream is an OutputStream. Where an OutputStream is expected, an InputOutputStream can be used. An OutputStream is a RewindableStream. If the few places that a RewindableStream is expected, which is during seeking, an OutputStream can be used. A RewindableStream is a BasicStream. In the places that a BasicStream is expected, which are setting and querying the flags and state, a RewindableStream can be used.

 

Besides, what point is the base class BasicStream? I don't see how it really serves a purpose.

 

The BasicStream class houses things common to all of the classes below it; my streams have a single "file pointer", and there are some operations that can be performed on both input and output streams alike. Additionally, the class defines enums and constants, and facilitates keeping track of the state, such as the error condition, and trivial flags. Sort of like std::ios_base.


#2Ectara

Posted 20 April 2013 - 11:42 AM

You rule out components, but I'm not sure why (you could potentially have a "reading" component, a "writing" component, a "rewinding" component, etc.)

 

since they both operate upon a common state, so composition would be out, since having two separate states would break the functionality.

Composition wouldn't be feasible, because the reading and writing depend upon a single offset within the file. In order to do this, the components would have to know about the base stream class' member variables, and interact with them, in order to manipulate a shared state. It seems like this is counter-intuitive, and that it would make more sense if the higher order classes were derived classes, since all of InputStream, OutputStream, and RewindableStream have an is-a relationship with BasicStream.

 

 

What you're trying to do violates the Liskov Substitution Principle.

I can't quite see how that is so. An InputOutputStream is an OutputStream. Where an OutputStream is expected, an InputOutputStream can be used. An OutputStream is a RewindableStream. If the few places that a RewindableStream is expected, which is during seeking, an OutputStream can be used. A RewindableStream is a BasicStream. In the places that a BasicStream is expected, which are setting and querying the flags and state, a RewindableStream can be used.

 

The BasicStream class houses things common to all of the classes below it; my streams have a single "file pointer", and there are some operations that can be performed on both input and output streams alike. Additionally, the class defines enums and constants, and facilitates keeping track of the state, such as the error condition, and trivial flags. Sort of like std::ios_base.


#1Ectara

Posted 20 April 2013 - 11:38 AM

You rule out components, but I'm not sure why (you could potentially have a "reading" component, a "writing" component, a "rewinding" component, etc.)

since they both operate upon a common state, so composition would be out, since having two separate states would break the functionality.

Composition wouldn't be feasible, because the reading and writing depend upon a single offset within the file. In order to do this, the components would have to know about the base stream class' member variables, and interact with them, in order to manipulate a shared state. It seems like this is counter-intuitive, and that it would make more sense since all of InputStream, OutputStream, and RewindableStream have an is-a relationship with BasicStream.

 

What you're trying to do violates the Liskov Substitution Principle.

I can't quite see how that is so. An InputOutputStream is an OutputStream. Where an OutputStream is expected, an InputOutputStream can be used. An OutputStream is a RewindableStream. If the few places that a RewindableStream is expected, which is during seeking, an OutputStream can be used. A RewindableStream is a BasicStream. In the places that a BasicStream is expected, which are setting and querying the flags and state, a RewindableStream can be used.

 

The BasicStream class houses things common to all of the classes below it; my streams have a single "file pointer", and there are some operations that can be performed on both input and output streams alike. Additionally, the class defines enums and constants, and facilitates keeping track of the state, such as the error condition, and trivial flags. Sort of like std::ios_base.


PARTNERS