I am currently attempting to refactor some legacy code. As it stands, I have a EX_User
class, which represents a generic user in the system I am working within. There are several other classes that extend the EX_User
class; for example the EX_Limited_User
class.
The EX_User
class extends an active record class that maps the EX_User
object to a row in a user table in the database.
I need to create a new type of user (e.g. New_User
) that is still data backed, but not in the same set of tables (and not via active record). Since the application I'm working in already passes these EX_User
objects around everywhere, I am looking to create a "new" single generic User
class, which would essentially be a common interface to all users (regardless of type). I would then change all references in my codebase to interact with this User
object, which may actually be represented by a EX_User
, EX_Limited_User
or New_User
.
I'm working in PHP (single inheritance), so I am unable to have EX_User
extend anything (as it already extends an active record type class).
I am looking for a good way to be able to achieve a single app facing user (generic User
interface), while still being able to implement that interface via any number of User implementations there may be (to facilitate a new user implementation, as well as backwards compatibility with the current user implementation).
Would anyone be able to give me a solid example as to how I might go about achieving this? Specifically how might I organize the classes listed above, and how would I go about passing around the general User
object in my code (as opposed to passing around objects of different types). I'm open to the idea of passing around different types of user objects and relying on ducktyping (or something) to achieve commonality, but I'd be afraid without a clear design, the code could quickly fall ill to poor modification.
I'd be equally thankful for an external reference to a pattern that could achieve this, though some googling hasn't turned up what I would call a "right fit" solution.
Thanks!
I think you can arrange your class a shown above, which will provide active record class to ex_user class and still you will have new backed method for generic user from your new record class. You will only need to change a super class ex_user using this approach.