按功能的文件夹和装饰器设计模式

Question

Folder-by-feature and decorator pattern

If I have a Parser that has an associated Stream , when I progress through the Tokens , I am mutating the state of the object as the Stream is moving forward. I want to add app-specific functionality to this parser to maintain the principle of single responsibility, so I thought the Decorator design pattern was an appropriate choice. I now wrap the Parser in a ParserDecorator(Parser) and add specific functions, such as readPerson() or readItem() that maps the data to an Object and returns that Object .

First, I considered making a static function within Person that takes the Parser as an argument; however, the function progresses the stream and I decided that would not be thread safe in all cases. As the ParserDecorator , though, return objects of different types, there is no way to keep it logically grouped with Person only. So if I change the Person class later, I have to remember to change how it is read by the ParserDecorator , which is located in a different part of the program and a new developer on the project may not check that location. Typically I deploy folder-by-feature so all the changes that would need to be made are located together, but it does not work in this case.

Is there a better solution to this case, working with a purely object-oriented approach? Right now I have a separate feature-folder called util that has this class.

EDIT: Example code:

public class JsonParserDecorator {
    private final JsonParser jsonParser;

    public JsonParserDecorator(JsonParser jsonParser) {
        this.jsonParser = jsonParser;
    }

    public Item readItem() throws IOException {
        Item item = new Item();

        if (jsonParser.currentToken() != JsonToken.START_OBJECT) {
            throw new IOException("JSON object expected");
        }

        while (jsonParser.nextToken() != JsonToken.END_OBJECT) {
            String fieldName = jsonParser.currentName();
            jsonParser.nextToken();

            switch (fieldName) {
                case "itemId":
                    item.setId(jsonParser.getLongValue());
                    break;
                case "description":
                    item.setDescription(jsonParser.getText());
                    break;
                default:
                    break;
            }
        }

        return item;
    }
}

Answer 1

I have come to a solution after thinking about it overnight. I created a new class called ItemJson and added read(JsonParser jsonParser) and write(JsonGenerator jsonGenerator, Item item) methods. This keeps all of the similar classes/features together and handles the reformatting of data in a single, separate class.