Menu
Community /Pin to ProfileBookmark
@NogDogNov 05.2011 — #I'm not sure we have enough info at this point to make any solid suggestions. However, it sort of sounds like you could organize things along a Model / View / Controller pattern (MVC).
The models would be the classes that store/retrieve data from the DB and handle any special business logic. The views would be the files that create any UI, and the controllers would be, well, the controllers that take requests from the UI, interface with the models, presumably fire of the REST requests and receive their results, and then ultimately transmit results to the users via more views.
As to whether to use abstract classes or interfaces, there can be some gray areas. Generally, though, interfaces are useful when you only need to establish that implementing classes are guaranteed to provide those method, while abstract classes can do that (by defining abstract methods within them) while also providing concrete methods as well as class properties that will be inherited by extending classes. As an example, for the REST stuff I might create an abstract class that defines the common aspects of any REST client, then extend it with concrete classes for each type of REST request (GET, POST, DELETE, PUT), so you might have an abstract RestRequest class that is extended by GetRestRequest, PostRestRequest, etc. classes.
A controller class might then choose which concrete REST class to instantiate at runtime based on the request from the UI.
OOP Question – Should I use abstract, interface, extends?
I’ve written a couple classes for pulling down REST data. One of the classes registers users and copies their info; another runs possible jobs and handles results. What should I do with the third part, that schedules jobs or has UI for creating jobs?
Anyway to rewrite this so I have one class for the UI methods the browser uses? Thanks!
[code=php]
class jobs extends utils
{
public $user;
public $userAccounts;
function __construct()
{
$this->getDb();
}
public function getUser() {
}
}
class jobQuery extends utils
{
public $errors;
public $log;
function __construct()
{
parent::getDb();
$this->countBatched();
$this->countRemaining();
}
public function saveQuery($q) {
}
public function runQuery($q) {
}
public function saveResult($r) {
}
}
class jobsUi extends jobQuery //?
{
public function saveQuery($q) {
print ‘Hi’;
$this->saveQuery($q);
}
public function editQueries($q) {
print ‘Careful!’;
$this->saveQuery($q);
}
public function runQueries() {
print ‘Look at this: ‘;
$this->runQuery($this->queries);
}
}
Sign in
to post a comment1 Comments(s) ↴
0
@NogDogNov 05.2011 — #The models would be the classes that store/retrieve data from the DB and handle any special business logic. The views would be the files that create any UI, and the controllers would be, well, the controllers that take requests from the UI, interface with the models, presumably fire of the REST requests and receive their results, and then ultimately transmit results to the users via more views.
As to whether to use abstract classes or interfaces, there can be some gray areas. Generally, though, interfaces are useful when you only need to establish that implementing classes are guaranteed to provide those method, while abstract classes can do that (by defining abstract methods within them) while also providing concrete methods as well as class properties that will be inherited by extending classes. As an example, for the REST stuff I might create an abstract class that defines the common aspects of any REST client, then extend it with concrete classes for each type of REST request (GET, POST, DELETE, PUT), so you might have an abstract RestRequest class that is extended by GetRestRequest, PostRestRequest, etc. classes.
A controller class might then choose which concrete REST class to instantiate at runtime based on the request from the UI.