Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move method refactoring. #171

Open
wants to merge 1 commit into
base: trunk
Choose a base branch
from

Conversation

Vivek504
Copy link

Move Method Refactoring

Reason: Feature Envy

  1. readSimpleValue is more interested in members of the type: Type1Font
  2. readFontInfo is more interested in members of the type: Type1Font
  3. readPrivate is more interested in members of the type: Type1Font
  4. readProc is more interested in members of the type: Type1Lexer
  5. readProcVoid is more interested in members of the type: Type1Lexer
  6. readMaybe is more interested in members of the type: Type1Lexer

Logic of Refactoring:

  1. For methods (readSimpleValue, readFontInfo and readPrivate), the code which is only dependent on Type1Font, that is moved to Type1Font class by creating a new method (readFontAttributes).
  2. readProc, readProcVoid and readMaybe: these methods are removed from Type1Parser class and moved to Type1Lexer class as all 3 methods are only interested on the members of Type1Lexer class.

@THausherr
Copy link
Contributor

This introduces a new public method in a class :-(

@lehmi
Copy link
Contributor

lehmi commented Nov 20, 2023

The parser is based in the lexer/parser principle. The lexer knows the lexical structure of the format and the parser itself uses the lexer to read an interpret the content of the files using the format. The Type1Font is the result of the parsing and doesn't need to know anything about the file format itself. According to that principle the moved methods end up in the wrong class. If we really want to change something, we might merge the lexer and the parser class, but in the moment I don't see any real reason to do so.

The implementation of readFontAttributes is, no offense, a no go. It is a wrapper for accessing the member values of the class. The huge switch statement would trigger our sonar scanner. A better approach is to introduce a setter for each value or an ever better solution is to introduce an additional class wrapping a couple of values which belong together, e.g. FontDirectory and FontInfo. Those classes could be used to initialize the Type1Font.

@THausherr
Copy link
Contributor

Sorry if I'm wrong, but I'm wondering whether this is a kind of public test of a new product on open source repositories to see how the humans involved react.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants