PHP Developers Network

I was just refactoring some functionality in my code base, moving away from 3 parallel sets of functions toward 3 class definitions which now expose the former functions as class methods. Some of the methods should be private. Some of the methods would have been completely identical across the 3 classes so what I've done is define those methods in a trait. Each of the 3 classes uses the trait. Because the 3 sets of functions mirrored one another, each with their own implementation, I've defined an interface which all 3 classes implement. I like that interfaces force the implementing class to expose all public methods defined in the interface. Methods in the trait call private methods in the classes, each of course having the same name so that the trait code does not break regardless of which class is using. The next goal I had was to enforce each class defining the private methods depended upon by the trait. I could of course manage this manually, but in team programming, for example, does it not now make sense with php's introduction of traits, that we have the ability to define the private methods a class must represent? My work-around to enforce the existence of would-be private methods in my 3 classes was to define them as abstract protected methods in an abstract class. My 3 classes extend that abstract class and of course define their own versions of the protected methods. Php does not allow one to define abstract private methods. Interfaces can only define public methods. I'm seeing a hole--I believe there is now a need, thanks to traits, to be able to define private methods that must be "exposed" by the class. I have achieved no code duplication and what I think is some highly maintainable code. But with traits, is php now missing something without a way to enforce the existence of private methods in classes?

What kind of methods are you talking about? Can you post the code?
Traits are basically just copy/paste so I'm wondering if putting those three methods in a trait is the best answer. And having a trait need to call methods that it doesn't itself define sounds like a bad thing.

The functionality that I refactored into 3 classes all deals with creating form controls. Each class handles a different GUI library each with its own HTML markup and Javascript function call requirements, etc. Each class implements an interface which consists of methods that are callable for creating GUI components for the web page being served. Since traits let you maintain methods common to multiple classes, I have the trait in place for that reason. But it is true that in some of my trait methods, those methods do make calls to private/protected/public methods that are defined in the class. What I've done is move all the common code I can to the trait. If I go with the idea you said about a trait not having any calls to class methods of the classes using the trait, then I will be moving code into the trait that does not need to be copied/pasted into other classes at execution time (code that does not apply to all classes that use the trait). I think php should have a way available to enforce/require classes to define specified private methods just as we can already do for public and protected methods. Putting it in database terms--I feel like I've normalized my code like one normalizes table design; that is, no duplicated data/code.

Traits can define abstract members, actually.

Lacking more detail, if so much code is the same then I'd probably put it in an abstract base class. That way it's more about common functionality than it is about three classes implementing methods the same way. If the base class needs more information that only the subclasses know, then you can use a couple protected abstract "helper" methods.