Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This is only IMHO, but having a large proportion of classes with names containing "manager", "context", "parser", etc. is a code smell. I'm not saying these kinds of classes are necessarily wrong -- certainly virtually every app has them. But think about it -- is a parser a thing you have, or is parsing a thing that an object does? Is there a real-world guy with the title of "API Manager"? Does he hang out with the Session Manager and ask you about your TPS reports? Etc.</p> <p>Think about your class design - I'm not saying it's "wrong" as it is -- because I haven't seen it and it's subjective anyway -- but are your classes modeling real-world entities, or are they modeling actions that can be carried out on entities? Or, even worse, are they modeling some kind of arbitrary workflow? Do your classes all have clearly defined responsibilities and not try to do crazy stuff that's none of their business?</p> <p>Basically, you're running into this problem because your class design is not optimal. In particular, if an instance of one class <strong>requires</strong> an instance of another class <strong>and</strong> vice-versa to work properly, you would probably benefit from rethinking your design.</p> <p><strong>Update in response to James' update</strong></p> <blockquote> <p>ApiManager.caller() - it's job is to go off to an API URL send GET variables, and retrieve results.</p> </blockquote> <p>One of the ideas of OOP is that classes represent entities (nouns) and methods represent actions (verbs). <code>ApiManager</code> here is an entity (kind of an abstract one, but we'll go with it) but <code>caller()</code> is not an action - i.e. you can't "caller" something. You could however <code>call()</code> something -- I guess in the context of ApiManager, this would "call" the API. I know it's only 2 little letters, but it makes a big difference in one's mental concept of what the ApiManager does.</p> <blockquote> <p>This caller() method is used by nearly all classes (perhaps a good reason for it to be in super class and extend the classes that need it?).</p> </blockquote> <p>Inheritance best used to support polymorphism, not code sharing -- I wouldn't do that...</p> <blockquote> <p>Part of the caller() responsibility is to check what API calls are being made. If a certain condition is met, it needs to stop and make a call to SessionManager.getNewSession() which goes off to the same API and retrieve a value. Only when this is complete can the original request ( in caller() ) be completed.</p> </blockquote> <p>One problem is that <code>caller()</code> shouldn't have a responsibility because it should be an action (e.g. <code>call()</code>), not a thing. Actions can't have responsibilities. It should just do something, preferably something simple. In keeping with the idea of ApiManager as a thing and <code>call()</code> as an action that ApiManager does, here is an example of the very bare minimum of how I might expect an ApiManager to work:</p> <pre><code>class ApiManager { private $session; private $url; // You'll probably need to set up the object differently; // this is just an example.... public function __construct($url) { $this-&gt;setURL($url); } function call() { if ($this-&gt;session is expired) { // instead of calling SessionManager.getNewSession() here, // why not just fold the session management functionality // into ApiManager? They both use the same API, after all... $session = $this-&gt;getNewSession(); } // do your call &amp; return the response } public function setURL($url) { $this-&gt;url = $url; } private function getNewSession() { // get a new session $this-&gt;session = $my_new_session; } } </code></pre> <p>You'll notice that all the methods in the class above are actions, they all do something. The icing on the cake is that there is no longer any need to worry about dependency injection for SessionManager, because it no longer exists! After all, an API session is really something that only the ApiManager needs to know about, no? :)</p>
    singulars
    1. This table or related slice is empty.
    1. POPHP OOP :: getting confused about Factory class and passing objects to constructors
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USalexantd
    1. USalexantd
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POPHP OOP :: getting confused about Factory class and passing objects to constructors
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. CO> "if an instance of one class requires an instance of another class and vice-versa to work properly" - topic starter is using dependency injection, whose main idea is to inject particular class instances into dependent class
      singulars
      1. PO
      1. USgalymzhan
    2. COThanks for the response. The app needs to connect to a third party API, and the APIManager object handles how objects interact with the remote API. I have grouped related methods and business logic into what I feel are sensible objects, such as Basket, Donation, Connection etc., and these objects make calls to relevant API methods. For example, the Basket object in my app contains methods that perform some business logic and then make requests to basket-related API calls. I agree re: your comment re: object requiring other object and vice-versa. I just need to work out how to decouple that...
      singulars
      1. PO
      1. USJames Agnew
    3. COA UML diagram might help, or some other way to sketch out your classes, what they do, and how they collaborate.
      singulars
      1. PO
      1. USalexantd
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload