Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #70551
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Subject | Re: Moving to an OOP model from an classically imperitive one |
| Date | 2014-04-23 22:15 +0100 |
| References | <80a82415-fc67-4ccf-8827-27a0ba5459b7@googlegroups.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.9469.1398287725.18130.python-list@python.org> (permalink) |
On 23/04/2014 21:57, tim.thelion@gmail.com wrote: > Hello, > > I am currently writting a program called subuser(subuser.org), which is written as classically imperative code. Subuser is, essentially, a package manager. It installs and updates programs from repositories. > > I have a set of source files https://github.com/subuser-security/subuser/tree/master/logic/subuserCommands/subuserlib which have functions in them. Each function does something to a program, it identifies the program by the programs name. For example, I have an installProgram function defined as such: > > def installProgram(programName, useCache): > > Now I've run into a flaw in this model. There are certain situations where a "programName" is not a unique identifier. It is possible for two repositories to each have a program with the same name. Obviously, I could go through my code and replace all use of the string "programName" with a tuple of (programName, repository). Or I could define a new class with two attributes: programName and repository, and pass such a simple object arround, or pass a dictionary. However, I think this would be better solved by moving fully to an OOP model. That is, I would have a SubuserProgram class which had methods such as "install", "describe", "isInstalled"... > > There is one problem though. Currently, I have these functions logically organized into source files, each between 40 and 170 LOC. I fear that if I were to put all of these functions into one class, than I would have a single, very large source file. I don't like working with large source files for practicall reasons. If I am to define the class SubuserProgram in the file SubuserProgram.py, I do not want all <https://github.com/subuser-security/subuser/blob/master/logic/subuserCommands/subuserlib/run.py#L162> of run.py to be moved into that file as well. > > I thought about keeping each method in a separate file, much as I do now, something like: > > ################### > #FileA.py > ################### > def a(self): > blah > > ################### > #FileB.py > ################### > def b(self): > blah > > ################### > #Class.py > ################### > import FileA, FileB > class C: > a=FileA.a > b=FileB.b > > This works, but I find that it is hard to read. When I come across FileA, and I see "self" it just seems very confusing. I suffer a bout of "who-am-i"ism. > > I asked on IRC and it was sugested that I use multiple classes, however I see no logical way to separate a SubuserProgram object into multiple classes. > > So I thought I would seek your advice. > > Tim > You're writing Python, not Java, so put your code into one file and stop messing about. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Moving to an OOP model from an classically imperitive one tim.thelion@gmail.com - 2014-04-23 13:57 -0700
Re: Moving to an OOP model from an classically imperitive one Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-23 22:15 +0100
Re: Moving to an OOP model from an classically imperitive one Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-23 15:23 -0600
Re: Moving to an OOP model from an classically imperitive one Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-24 12:26 +1200
Re: Moving to an OOP model from an classically imperitive one Ethan Furman <ethan@stoneleaf.us> - 2014-04-23 14:42 -0700
Re: Moving to an OOP model from an classically imperitive one tim.thelion@gmail.com - 2014-04-24 00:32 -0700
Re: Moving to an OOP model from an classically imperitive one MRAB <python@mrabarnett.plus.com> - 2014-04-24 00:08 +0100
Re: Moving to an OOP model from an classically imperitive one tim.thelion@gmail.com - 2014-04-24 00:21 -0700
Re: Moving to an OOP model from an classically imperitive one Chris Angelico <rosuav@gmail.com> - 2014-04-24 17:36 +1000
Re: Moving to an OOP model from an classically imperitive one Steven D'Aprano <steve@pearwood.info> - 2014-04-24 09:08 +0000
Re: Moving to an OOP model from an classically imperitive one Chris Angelico <rosuav@gmail.com> - 2014-04-24 09:12 +1000
Re: Moving to an OOP model from an classically imperitive one Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-24 12:21 +1200
Re: Moving to an OOP model from an classically imperitive one tim.thelion@gmail.com - 2014-04-24 09:53 -0700
Re: Moving to an OOP model from an classically imperitive one Amirouche Boubekki <amirouche.boubekki@gmail.com> - 2014-04-25 19:21 +0200
Re:Moving to an OOP model from an classically imperitive one Dave Angel <davea@davea.name> - 2014-04-23 22:01 -0400
csiph-web