Single Responsibility Principle: Should I separate my bibliography class in Reader, Writer and Container class?

Question

cowboy coder needs some help from SO-veterans:

I have a given application that uses a bibliography which is read from a file (in reality, it can be different files but let's assume a single file only).

I build a new application that should use the bibliography the same way than the application so I copied the according class(es).

After some days I got things running %-| ...

Problem was the following:

In the Bibliography class there is code to read, write and keep the bibliography. My work would have been much easier when there would have been one class to read the bibliography and a container class that keeps all values. I don't want to write or edit the bibliography, just read it in and keep the values.

So am I right in my idea that it would be best to segment the bibliography class into a BibliographyReader, BibliographyWriter and a Bibliography(Container) class?

P.S.: Could someone please create a tag "cowboy coder", "cowboy coding" or something similar? I really miss this tag ;)

Answer 1

I like the approach of separating "container" classes from reader/writer/getter and so on, preferably defined by an interface. Search for "strategy pattern" and you will find more information about it.

A simple approach would be to have the Bibliography class accept an IBibliographyReader in its constructor, and then have a class implement that interface. When creating a Bibliography class you pass an instance of the concrete reader implementation to it.

Answer 2

I would split the responsibilities as follows:-

• Bibliography: holds the data related to the bibliography. It would receive this data in it's constructor or via setters
• BibliographyFileStreamReader: responsible for reading the bibliography (given a file stream). It returns a Bibliography instance

You may also add a BibliographyFileStreamWritter.