PHP dynamic vs. static method naming convention

Question

Disclaimer: See my updated answer below. The code in this question is an example of several bad practices and should not be immitated.

I am trying to determine the best naming convention to use for my database-derived classes. I often run into cases where I want to have both static and dynamic methods with similar functionality.

For example say I have a company class. Each company has a variety of products that they offer. In my company class I want to be able to retrieve all the ids of products that one or more companies offer or set associations between companies and products.

class Company {

     /** STATIC FUNCTIONS **/

     public static function GetProductIds($company_ids = array()){

          $company_ids = (array)$company_ids;

          // retrieve associated product ids from database

          return $product_ids;

     } // GetProductIds()


     public static function SetProductIds($company_ids = array(), $product_ids = array()){

          $company_ids = (array)$company_ids;
          $product_ids = (array)$product_ids;

          // insert company/product associations into database

          return true;

     } // SetProductIds()


     /** DYNAMIC FUNCTIONS **/

     public function ProductIds($product_ids = null){

          if($product_ids){
               return self::SetProductIds($this->company_id, $product_ids);
          }

          return self::GetProductIds($this->company_id);

     } // ProductIds()


} // CLASS Company

In this example calling the dynamic ProductIds() method allows me to either set or get data with the same method. However, I may have cases where there is no setting functionality for a dynamic method.

Does anyone have recommendations on whether this is an acceptable strategy? If not what how do you set up your methods to handle these cases?

Answer 1

Update: I figured I would update this answer since it's gotten a decent amount of views and my original answer was... bad. @Felippe Duarte's initial comment to my question was absolutely correct. I was mixing business logic into all of my model classes and overusing static methods and properties waaaaaay too much. I now try to avoid static methods whenever possible, break large, broad classes into multiple classes with more specific concerns, and leverage dependency injection to reuse services throughout my application. I didn't have any experience with frameworks back when I wrote this, and it's pretty painful to come back to and read now haha.

Original (bad) answer:

I've decided against setting up my classes this way. My main reason against it, which Barmar pointed out in his comment, is that the dynamic method's name does not explicitly describe what it does (as it can either set or get). I will be keeping my get/set methods separate to keep things clear.

Give your methods names that describe what they do. Don't worry about naming conventions for static vs. dynamic. Worry more about private vs. public -- does the method that saves to the DB really need to be public? It looks like it's an internal utility for the other methods. – Barmar

I will also be using something like BulkGetProductIds() when naming static methods where I need to get data based on multiple ids.