0

I am creating a schema for Doctrine but first I'm creating interfaces, abstract classes (models) which will be extended by the entities.

I have a PresentationInterface which contain getter and setters for presentation info, ParticipantInterface which contains the same (firstname, lastname, email).

Both have their abstract classes, Presentation and Participant which implement the getter and setters and also contain mapping information for those fields. They may contain some utlity methods which are not defined in the interface but are needed inside the getter and setters for processing data.

The entities are Presentation, Attendee and Presenter. Attendee extends from the Participant model, and Presenter from Attendee. Now to differentiate I'm using Doctrine's single table inheritance type with a discriminator column called is_presenter which is mapped at Attendee entity.

Basically, a Presenter is able to create a Presentation which thereafter is joined by Attendees.

My question is, should isPresenter have been defined in ParticipantInterface? Is the way I've done it worse or fine? If I had left it in the interface, I couldn't use it as a discriminator anyway, but from a logical point of view should it have been in the interface or maybe in another called PresenterParticipantInterface?

Improve this question
6
  • This seems like the classic anti-pattern of designing an object hierarchy around the real world objects you're modelling rather than the operations you want to perform on that model (e.g. create presentation, join audience, etc). For instance, why do you need/want separate Presenter and Attendee classes? And how do you deal with Presenters who attend other people's presentations?
    – Ixrec
    Jun 30, 2015 at 16:53
  • @Ixrec: You're damn right, I didn't think about presenters attending other's presentations. So what do you suggest, keeping a single Participant entity and keeping a track of who presents with an isPresenter field? And ultimately, that should be part of the interface as well?
    – user185486
    Jun 30, 2015 at 16:59
  • The first thing that comes to mind is you may be better off with a Presentation class which has presenter and attendees fields of type PersonID and list thereof. But this is merely one symptom of the fundamental issue I wanted to point out; namely that you appear to be thinking about types of objects before thinking about what you want them to do. Issues like this always crop up when you do that.
    – Ixrec
    Jun 30, 2015 at 17:02
  • @Ixrec: Classroom is kinda the Presentation class you're describing. It can contain 1 presenter and multiple attendess. I already know what I want to do with these objects. Presenters can create classrooms (presentations) in which attendes can join. There is more to it but nothing crucial that changes the fundamental architecture.
    – user185486
    Jun 30, 2015 at 17:06
  • Ah, I see. The name made me assume it represented actual physical rooms, rather than the more abstract idea of a presentation. Though again, this shows how important it is to write down what all these interfaces/classes are meant to do, rather than simply state their names.
    – Ixrec
    Jun 30, 2015 at 17:08

1 Answer 1

Reset to default
2

I have no idea what Doctrine is, but from what you are describing looks like ORM.

Regardless, I will speak from SOLID and software design perspective.

I would apply ISP(Interface Segregation Principle from SOLIDs) and have a number interfaces: IAttendee, IParticipant and IPresenter with their own respective methods.

So you could have variations of objects that conform to specifi set of interfaces:

public class Attendee extends Participant implements IAttendee { }
public class Presenter extends Attendee implements IPresenter {}
public class Auditor extends Attendee implmenets IAuditor {}

Use interfaces to your advantage, don't just meaninglessly create them because you were told to do so. Mix and match them :)

Improve this answer
2
  • Is it meaningless to create an interface? afaik, an interface describes a contract and the public API. Abstract classes might be meaningless sometimes but I don't see why not creating interfaces. Decoupling is another reason.
    – user185486
    Jun 30, 2015 at 17:02
  • @GlendGjermeni I didn't say it's meaningless to create an interface, but to create one meaninglessly certainly is :)
    – Alexus
    Jun 30, 2015 at 17:04

Your Answer

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