I am attempting to learn object oriented programming by designing a simple web application related to the Catholic liturgical calendar. I have very little formalized training in programming, but I have been able to more-or-less successfully learn basic programming concepts and the purposes/syntax of a couple languages.

I was hoping that I could receive feedback on the following design I have worked out and implemented in testing. The basic use case is to be able to find the calendar details of any date and time through both application logic and some database queries. I have developed the classes as such:

class Year
    create several DateTime objects for important movables feasts for a year

class Season extends Year
    create several properties for each liturgical season based on the DateTime
    objects from Year and additional application logic

class Day extends Season
    contains an array of Hours objects since a liturgical day is not necessarily
    the same as a 24 hour temporal day

class Hour extends Day
    determines the liturgical hour details including the feast being celebrated
    and DateTime objects representing the start and stop times of the hour since
    and "hour" <> a temporal hour of 60 minutes

With this design, I can create an Hour by passing a single parameter ($date). The Hour needs to know which liturgical season it is for some application logic, so it creates a Season object based on $date. The Season object, however, cannot be created until it knows when certain important feast days occur in any given year (e.g. Easter determines the start and stop dates for several liturgical seasons), so it creates a Year object. Is this a "desirable" pattern such that to create a single desired object (Hour) two other objects (Season and Year) are created? Is it "proper" to extend classes to reflect a hierarchical relationship such as I have (i.e. the largest temporal period is "at top", followed by the largest subdivision of that, etc...down to the smallest temporal period of hour)?

The primary purpose of this web application will be to display religious facts and literature based on the current liturgical hour. Thus, the Hour is the most important piece to the end user - but this cannot be determined successfully without the "larger" periods of Season and Year. The Day object will be used for navigation/information purposes only (e.g. what are the important religious occurrences at all the liturgical hours today?) and will likely not include any actionable events within it.

In testing, I have created a year's worth of Date objects which results in 2,920 Hour, Season and Year objects (365 * 8 for each object type = 8,760 total objects). The application logic is correct and produces desired data results. However, this seems like an incredibly high number of object instantiations for such a simple system, so I would like to know if I am misusing objects or totally misunderstanding their purpose. I think it may be more desirable to be able to create a single Year object which would produce 13 Season objects that could then be referenced by each Hour that I need to create...thus creating only 2,934 objects (2,920 Hour, 13 Season and 1 Year).

Any thoughts would be appreciated!


1 Answer 1


What I think @SlappyTheFish is getting at in his comment is that with extension you're basically telling your code that a Season IS a Year. When in reality, a Season IS NOT a year, a year HAS seasons. That's basically the reference to is-a and has-a that he had mentioned.

Now looking at encapsulation you would have:

  • 1 year object
  • 4 Season Objects, contained within a Seasons array inside Year.
  • Each Season object would contain an array of Day objects (The number to correspond to the correct distribution of days to Seasons)
  • Each day object would contain an Hours array, which would contain 24 Hours objects.

Whether or not this is the best design is a different question, but it gives you an idea of encapsulation instead of inheritance.

  • 1
    Thank you for the information! It seems, then, that I may have incorrectly interpreted a few principles/goals with this design: 1. Objects which may use of other objects are not necessarily "related" to one another by the "Is A" logic, even if one object is dependent on another object. 2. An object that requires another object does not (and probably should not) create the required object itself. I think a more appropriate design would be to inject the object dependencies through the constructor (e.g. create 1 Year, then create X Season objects each of which is passed the Year object). Aug 27, 2014 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.