Help defining OOP Classes for submission form

I’m fairly new at OOP php and looking at taking a long form that I have and re-creating it using an OOP approach. An older version was built using a procedural approach.

Basically, the form:

  • gathers input
  • allows multiple file uploads
  • saves submission to database
  • sends email notification of submission

Here’s what the form looks like (there are more fields than shown):

Since the form has lots of submission fields, is it appropriate to have so many parameters passed to the constructor?

I wasn’t sure if I should just have a single class to handle the submission OR to have the fields split up into multiple classes based on their subject area (i.e. 1 to 1 Activity, Live Event Activity, Joint Venture Activity, Networking and Social Media Activity). If going this route, I will still need to submit ALL data into one database row.

Any insight would be appreciated!

Well, I have used OOP little for forms, but, here is a good tutorial on it. It is basically for a simple form, but, you can alter it as needed. I think this would be a good starting place for you. Then, post problems and we can try to assist you further.
Register Form in OOP

1 Like

OOP is not about surrounding parts of your main code in class definitions and adding $this-> in front of everything in order to make it work. This is just exchanging one defining/calling syntax for another and adding a lot of typing, without adding a any value.

Any user written Class or Function should be general purpose, reusable, and be responsible for doing one thing, i.e. they should be building blocks that help you to write applications. They should not contain any application specific value, code, or query that you would need to touch just because you move an application to a different server/domain or write an application that does something different. After you design, write, test, and debug any user written Class or Function, you should be able to tuck it away in a file in a folder, then just load the definition and use it when needed. If you are constantly editing or copy/pasting/renaming Classes or Functions, it is a sign that your code has the wrong responsibility and is not general purpose.

If you have more than about 2-3 inputs, you should use a data-driven design, where you have a data structure (array or database table) that defines the expected inputs, the validation steps, and the processing for each input. You would also keep the input data as an array and operate on elements in that array using array functions (arrays are for sets of data where you will operated on each member in the set in the same or similar way.) You would then dynamically validate, then process the data, by looping over the defining structure and use general-purpose code to perform operations on the data. If you find yourself writing out line after line and block after block of code that only differs in the input value it operates on, it is a sign that you are doing things the hardest way possible. You are not using the computer as a tool to help you accomplish a task, you are doing the work yourself.

1 Like

I would add a further point - you should initially only design, write, test, and debug the code needed for one form field, of each type, then once you are satisfied with the design and operation of the code, deal with the code needed for all the rest of the form fields (hopefully using a data-driven design as suggested.) Writing out code for around 100 fields (the image of the constructor), that will likely get changed several times before you arrive at the final design, is a huge amount of wasted typing.

1 Like

Thanks for your feedback! I haven’t really touched on data-driven design so far and only worked with procedural and oop, so I’ll dive in into this.

I’ll add that a class doesn’t have to be for the entire form, it can be separated out. Anytime you have that many parameters for a constructor it’s a massive code smell. An object or several make more sense.

@astonecipher Would you approach this using OOP? If so, how would you separate the classes based on that form screenshot?

Use the “IS-A” “HAS-A” relationship model. Model your classes based on the data needed/ expected. Name and email have nothing to do with prospects, but they do have a relationship to each other.

“Activity” is a class, 1-1 vs live can be inherited from the parent Activity class.

Make sense?

Sponsor our Newsletter | Privacy Policy | Terms of Service