OOP PHP – Avoiding One Class Per Table Situation

object-orientedobject-oriented-designPHP

I am working on a project of an online service provider.

I have tables for admin, agent, customer and tables for data storage like city, services, category, sub-category, gender.

I have created classes for the admin, customer and agent.
But should I create classes for city, services, category, etc or use as methods in admin, customer and agent.

note:- I want to perform CRUD operation for city, services, category, sub-category, gender tables.

Is it good to have one class for each table in a database? If not then please explain how to avoid this situation?
Can I use enum or ArrayList instead of class for data storage?

Best Answer

Put them in their own class (city, services, category, sub-category, gender). Why wouldn't you? Is there a concern that you'll have too many classes that interact with the data storage?

If you want to expand on any of these entities, there would be no reason to change the: customer, agent or admin classes. That doesn't mean a customer can't be associated with many cities in some sort of list/array, but when it comes to managing the cities themselves, why bother the customer code? If you associate a city with a country, parish or province, try not to mess with anything else.

A few months down the road, either you or a new/additional developer may need to modify how the category or sub-categories work, so wouldn't it be pretty simple to start with those classes?

If it wasn't for the design of your database, how would you handle it? Many proponents of OOP, suggest holding off on database/storage decisions until you get the business logic and requirements established.

Related Topic