Design Pattern Question

Question

I'm relatively new to the world of OOP, and having read through some design patterns, I'm struggling with that 'aha' moment.

I have the following objects Event (Single event, with start time and end time, and it's availability) EventCollection (Contains multiple instances of the Event, either cloned and set, or instantiated with 'new', and a date attribute) Booking (With a collection of EventCollections)

This in turn, gives the ability to pick multiple event 'slots' per day.

The object, EventCollection will either contain static pre-computed time 'slots', for 'picking', or a set of Events for which have been booked.

Now my first stab at this, at least up to the point of EventCollection has been along these lines

class Event {
 protected startTime
 protected endTime
 protected status //available, booked, unavailable
 public function __construct(startTime, endTime, status = 'available')
 {
 this->startTime = startTime
 this->endTime = endTime
 this->status = status
 }
 public function changeStatus(status)
 {
 this->status = status
 }
 public function getStatus()
 {
 return this->status
 }
}
class EventCollection {
 protected date
 protected events
 public function __construct(date)
 {
 this->date = date
 }
 public function buildAvailableEvents()
 {
 // Loop through construction of events calculated by pre defined offsets
 this->events[] = new Event(startTime, endTime, 'available')
 }
 public function populateFromDb(SomeInterface db)
 {
 // Loop through construction of events determined by the interface of a database source
 this->events[] = new Event(startTime, endTime, status)
 }
 public function getAvailableEvents()
 {
 return this->getEvents('available')
 }
 public function getBookedEvents()
 {
 return this->getEvents('booked')
 }
 public function getUnavailableEvents()
 {
 return this->getEvents('unavailable')
 }
 protected function getBlocks(status)
 {
 selectedEvents = []
 foreach (this->events as event) {
 if(event->getStatus() == status)
 {
 selectedEvents[] = event
 }
 }
 return selectedEvents
 }
}
class Booking {
 protected name
 protected email
 protected moreCustomerDetails
 protected EventCollection
 public function __construct(name, email ...)
 {
 this->name = name
 this->email = email
 }
 public function addEventCollection(EventCollection eventCollection)
 {
 this->eventCollection[] = eventCollection
 }
}
//Client
booking = new Booking('me', '[email protected]')
eventCollection = new EventCollection()->buildAvailableEvents()
booking->addEventCollection(eventCollection)

Is this conforming to any pattern? I feel I'm missing something due to the fact I'm just using objects as simplified holders of arrays of objects. Can this be refactored into any such patterns to reduce class bulk? I do see some duplication of code, but have simply refactored that within the same class.

I have tried to separate into single responsibilities.

Can anyone suggest any improvements? This isn't operational code, I've just semi-stubbed it up.

• Jit B: patterns are to help you write better and maintainable code - you dont have to force your program to follow a pattern if it does what it's supposed to be doing. In this case your program looks fine. You might want to go through the GoF Design Patterns book to learn about more maintainable patterns.

Answer 1

Design patterns are "best practice" solutions for challenges that occur frequently when designing software. The benefit of design patterns lies in

• If you find that your problem (nearly) fits a design pattern, you have a short name to call your problem by, which eases communication with others
• The solutions presented in design patterns are generally well researched and the advantages, disadvantages, challenges in implementation and when not to use it are usually well documented.

On the other hand, design patterns do not and will never cover all aspects of a design. They are usually focused more on design challenges that have non-trivial solutions or trade-offs.
A composition of (collections of) classes as you show in your example is not described in any design pattern I know of. This is not bad and is most likely because it is not considered a big enough design challenge to justify the effort it takes to write a design pattern about.

• Big-G: Thanks for taking the time to explain this, I guess ultimately I was looking for a label, but I suppose, not everything needs a label if it's so simplistic and small to read and understand.