Question

Imagine you have a page that is of a specific page type (for example normal page, account page etc). The page is represented by a Page object.

My question is, how would you assign a page type to a page?

I see these options:

1. by using a PageType enum that is set in the Page object.
2. by using a PageType class, and assigning instances of it in the Page object.
3. by using page tags, which are simple strings associated with the Page object.

Option 1 is code-only approach, so adding new page types means changing (core) code.
Option 2 is more flexible, but there is additional overhead in having to maintain these page types.
Option 3 is very flexible, because there’s no maintenance and it’s extendable to other mechanisms than page type. But you can easily break things because there are no constraints.

What would be other objective reasons to choose one over the other?

Answer 1

There is a lack of details regarding a system design and pages requirements, number of different page types to support and difference between pages itself, so hard to make such decision. In such case I would recommend to keep it simple and use Enum.

• If pages has own specific business logic you can stick with class per Page type, but do it carefully only when really page-specific logic there.
• Think about UserControl/CustomControl feature (assuming you are usign ASP.NET) so you can split page by a set of controls which is responsible on the part of Page functionality, so in this way you’ll keep Single Responsibility Principle and build less coupled system.
• Some logic should be extracted from Page entities itself into external helpers/factories/repositories and then injected in Page class.

Regarding objectives,
you should define how many pages could be in place potentially and which level of flexibility should be provided. Also keep in mind such things like extensibility and maintenance of a system.