0

I have one class user that is initiated in /update/user.php when update.php is started. This class handles user related queries on the database, such as edit, delete, create, etc.

I'm in the process of creating a new class also named user in /src/user.php that will perform user related queries on the database but only to retrieve them (and output) them. Such as to retrieve their user id, usergroup, e-mail, etc.

I find the need to name them both user but obviously there will be conflicts when update.php is retrieved. What suggestions can you give for naming these two different classes, even though they are seperate areas in my library but perform similar operations?

Using PHP 4.

Jared
  • 2,978
  • 4
  • 26
  • 45
  • 2
    You should not under any circumstances be doing new development in a language considered dead by the developers for 2+ years. That said, it also won't impact the answer to this question in any meaningful way... – Charles Mar 16 '11 at 07:16
  • I would love to upgrade to PHP 5. – Jared Mar 16 '11 at 07:22
  • You probably have compelling reasons why you can't switch to 5, but to reiterate because it's really important: PHP 4 is a dead horse, does not even get security hotfixes any more, and has much more limited OOP capabilities than 5. Learning PHP 4 from scratch in 2011 is *very* unusual. If your employer/client/whatever has a legacy production app running on 4, they really should consider switching it to 5 - especially if it's public-facing. It's usually not that painful. – Pekka Mar 16 '11 at 07:32
  • My employer actually mentioned upgrading to PHP5 a few days ago. He hopes to upgrade (and move all of the legacy projects) to PHP5 in the next few months. – Jared Mar 16 '11 at 07:36

5 Answers5

2

If they both query, but only one writes, then I would suggest something like.

UserWrite
UserRead

or

UserCreate
UserAccess
Fraser
  • 15,275
  • 8
  • 53
  • 104
  • I have considered this, however `UserWrite` would only be initiated when I want to perform an operation on the user, which would occur much less than `UserRead`. That's why I have this pickle. I will definitely consider your suggestion. – Jared Mar 16 '11 at 07:24
  • I've opted for adding a prefix to the `user write` class, and leave the `user read` class to `user` for the time being. Thanks for the suggestion. – Jared Mar 16 '11 at 07:46
  • Actually, could it be possible for `user write` to be a "sub class" of say, `update`? So if I wanted to create a new user, I would call `$update->user->create` instead of `$user->create`? – Jared Mar 16 '11 at 07:50
  • @Jazza, sure that makes sense too. – Fraser Mar 16 '11 at 10:06
2

To present an alternative to the whole naming structure instead of just suggesting names. The Zend Framework and other libraries have a naming structure that corresponds with the file's position in the tree. Half-fictitious example:

Class name               Is in
-----------------------------------------------------------
Zend_Auth                /Zend/Auth.php
Zend_Auth_Adapter        /Zend/Auth/Adapter.php
Zend_Auth_Helper         /Zend/Auth/Helper.php
Zend_Auth_Adapter_HTTP   /Zend/Auth/Adapter/HTTP.php

so the underscore is the directory separator, and the last element of the name is the PHP file's name.

The main reason for this is that it makes autoloading extremely easy, but it's also a nice way for ordering libraries by task. Also, when you see a class used somewhere in your code, you can always tell which file it is in which is a great plus.

In your current method, the problem I see is that "src" is a very unclear description of what that class actually does. Maybe a more telling name (like "tools" or "query") would be in order, or maybe the main user class and should just be named "user"?

Applying the abovementioned example to that structure could result in

Class name                   Is in
------------------------------------------------------------
MyAppname_User_Update        /User/Update.php
MyAppname_User               /User.php

Oh and, what @Charles says in his comment. You should absolutely not be developing for PHP 4 any more. It is a dead version, and is no longer supported.

Community
  • 1
  • 1
Pekka
  • 442,112
  • 142
  • 972
  • 1,088
  • agreed , ZF naming convention is indeed pretty good one to adopt – add9 Mar 16 '11 at 07:24
  • Interesting naming convention. I wouldn't have considered it at all. I'm declined to use it though because I'm in a (long) learning phase of php, and my library's file structure changes often. – Jared Mar 16 '11 at 07:27
  • @Jazza I know what you mean, fair enough. – Pekka Mar 16 '11 at 07:32
0

I understand your question, but do you think that you really want to create 2 different classes to perform the same action? You can just create it in /src/user.php and obviously can use it wherever you want. You should make methods in that class in such a way that they will be used in both the problems. i.e in retrieving information and also in updating it.

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
adn295
  • 21
  • 1
  • 1
  • 2
  • Not really. I have split the two to keep them distinctly separate because although they operate on the same thing - users - they perform "opposite" functions. – Jared Mar 16 '11 at 07:28
0

In OOP, your update.php is called BaseDAO.php and user.php is call UserDAO.php (Data Access Object). But since you don't use OOP, I guess use can name it BaseService.php and UserService.php

ngduc
  • 1,415
  • 12
  • 17
0

I would suggest you create one class to create, edit, delete, and retrieve records related to the users. Then manage user Roles to limit the access to the methods, rather than creating two separate class for one object class.

Explanation with comparison to real world.

Let's say we have class Car. When user with Mechanical Role (or a mechanic) uses the car class then, he will able to access methods like repair(), openHood(), where as when users with driving role (or drivers) will access drive() methods.

In this scenarios also it is very inappropriate to create CarMechanic class and CarDriver class.

I think I made my point.

Starx
  • 77,474
  • 47
  • 185
  • 261