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.

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.