Note that there are some explanatory texts on larger screens.

plurals
  1. POPython: how to design a container with elements that must reference their container
    primarykey
    data
    text
    <p><em>(The title is admittedly not that great. Please forgive my English, this is the best I could think of.)</em></p> <p>I'm writing a python script that will manage email domains and their accounts, and I'm also a newby at OOP design. My two (related?) issues are:</p> <ol> <li>the Domain class must do special work to add and remove accounts, like adding/removing them to the underlying implementation</li> <li>how to manage operations on accounts that must go through their container</li> </ol> <p>To solve the former issue, I'd add a factory method to the Domain class that'll build an Account instance in that domain, and a 'remove' (<em>anti-factory</em>?) method to handle deletions.</p> <p>For the latter, this seems to me "anti-oop" since what would logically be an operation on an Account (e.g., change password) that must always reference the containing Domain. It seems to me that I must add a reference back to the Domain to the Account and use that to get data (such as the domain name) or call methods on the Domain class.</p> <p>Code example (element uses data from the container) that manages an underlying <a href="http://www.qmailwiki.org/Vpopmail#Command-line_utilities" rel="nofollow noreferrer">Vpopmail</a> system:</p> <pre><code>class Account: def __init__(self, name, password, domain): self.name = name self.password = password self.domain = domain def set_password(self, password): os.system('vpasswd %s@%s %s' % (self.name, self.domain.name, password) self.password = password class Domain: def __init__(self, domain_name): self.name = domain_name self.accounts = {} def create_account(self, name, password): os.system('vadduser %s@%s %s' % (name, self.name, password)) account = Account(name, password, self) self.accounts[name] = account def delete_account(self, name): os.system('vdeluser %s@%s' % (name, self.name)) del self.accounts[name] </code></pre> <p>Another option would be for Account.set_password to call a Domain method that would do the actual work - which sounds equally ugly to me.</p> <p>Also note the duplication of data (account name also as dict key), it sounds logical (account names are "primary key" inside a domain) but accounts need to know their own name.</p> <p>EDIT: please note the above code is just a quick example, think of it as pseudo code. It intentionally does not care about error conditions or security issues, and is incomplete in data and methods of the classes (per-user spam settings, auto-responders, forwarders, get mailbox size, etc...).</p> <p>Also, this is an example I had at hand, but I think it could be generalized to other different logical structures similar to trees where nodes must know about their children and children must call into parents (or upper level ancestors) to do things. To me, this sounds logically similar to class inheritance but applied to instances of different types (classes) linked to each other.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

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