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

Rename DimensionContent to Content #90

Open
niklasnatter opened this issue Feb 25, 2020 · 1 comment
Open

Rename DimensionContent to Content #90

niklasnatter opened this issue Feb 25, 2020 · 1 comment
Labels
Technical Debt Impacts only code quality, no or just small impact on end developers and users To Discuss The core team has to decide if this will be implemented

Comments

@niklasnatter
Copy link
Contributor

niklasnatter commented Feb 25, 2020

At the moment, the bundle uses a Dimension entity and a DimensionContent entity. Each DimensionContent is associated to exactly on Dimension. To manage these entities, the bundle additionally contains the following classes:

  • DimensionCollection (+ DimensionCollectionInterface)
  • DimensionContentCollection (+ DimensionContentCollectionInterface)
  • DimensionRepository (+ DimensionRepositoryInterface)
  • DimensionContentRepository (+ DimensionContentRepositoryInterface)
  • DimensionCollectionFactory (+ DimensionCollectionFactoryInterface)
  • DimensionContentCollectionFactory (+ DimensionContentCollectionFactoryInterface)

In theory, DimensionContent is a good name because it expresses that the entity contains content in a specific dimension. But in practice, i dont think it is a good idea to include Dimension in the name of the entity.

I think the Dimension prefix makes it hard to distinguish the DimensionContent entity from the Dimension entity. Especially when using composite service names (eg. DimensionContentCollection or DimensionCollectionFactory), it is very hard to see which entity is managed by the service. The makes the code unnecessarily hard to comprehend and impossible to understand/navigate it quickly. Also it is hard to talk in person about the concepts, because the terms are just too similar (eg. DimensionCollection and DimensionContentCollection).

This issue is either solvable by removing the Dimension entity as suggested in #83, or by finding a better/simpler name for the DimensionContent entity. The following names might be better suited:

  • Slice / ContentSlice (leads to NewsSlice instead of NewsDimensionContent in a project)
  • Layer / ContentLayer (leads to NewsLayer instead of NewsDimensionContent in a project)
  • Partial / ContentPartial (leads to NewsPartial instead of NewsDimensionContent in a project)
@niklasnatter niklasnatter changed the title Find a better name for the DimensionContent entity Find a better/simpler name for the DimensionContent entity Feb 25, 2020
@niklasnatter niklasnatter added Technical Debt Impacts only code quality, no or just small impact on end developers and users To Discuss The core team has to decide if this will be implemented labels Feb 25, 2020
@niklasnatter
Copy link
Contributor Author

After #174 is merged, there will be no Dimension entity in the codebase. This partially solves this issue because it is not necessary to distinguish between Dimension and DimensionContent when reading through the codebase anymore.

That said, I still think it would make sense to rename the DimensionContent to something simpler. IMO, there is no reason for including Dimension anymore. Therefore I would prefer to just use Content as a replacement for DimensionContent.

@niklasnatter niklasnatter changed the title Find a better/simpler name for the DimensionContent entity Rename the DimensionContent class to Content Jan 18, 2021
@niklasnatter niklasnatter changed the title Rename the DimensionContent class to Content Rename DimensionContent to Content Jan 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Technical Debt Impacts only code quality, no or just small impact on end developers and users To Discuss The core team has to decide if this will be implemented
Projects
None yet
Development

No branches or pull requests

1 participant