Best approach to OO Style (only slightly off topic)?

Chris Angelico rosuav at
Fri Feb 1 16:17:43 CET 2013

On Sat, Feb 2, 2013 at 1:24 AM, Steve Simmons <square.steve at> wrote:
> At this point, I began to wonder what a 'correctly structured' OO program
> should look like. Should I separate GUI logic from 'business' logic?  Should
> everything be in one class?  Should my main() be carrying the high level
> logic?  Anyinput most welcome.
> I looked briefly at the MVC model which answers my question at a high level
> but itrepresents another learning curve that I'm reluctant to add to my
> current challenge.

Rule #0 of design: There's always a worse pattern you could have used.

Python gives you all the flexibility you could want. And with that
flexibility comes ease of complication. The key is to find the
simplest design that will accomplish what you want, and go from there.

The idea of separating out "business logic" from "user interface"
seems all very well on the face of it, but it's often harder than you
might think, and when you force an application into that kind of
segregation, you'll often end up with thin layers around one or the
other so there's really UI code interspersed with "guts" code despite
your best efforts. Drastically changing your UI will generally involve
lots of code changes anyway, so don't be too bothered if you find you
need to change something that didn't feel like "user interface" code.

Model/View/Controller systems tend, imho, to be massive overkill for
anything smaller than Huge. In fact, I can't point to any MVC system
that fitted onto a single computer that couldn't have been done better
with something rather simpler.

Above all, don't have one class for "someone else's code" and one for
"my code" unless there's some really REALLY good reason for it. A
better model in Python would be to have two *modules*, not two

But there are myriad ways you could lay out your code, and few of them
are truly *wrong*. The most important thing to do is to think about
what you do; plan, don't just let it grow by itself. The plan
shouldn't be chiseled into basalt, but any time you change it, be sure
you know why you're changing it.

You say you're new to OO; what programming model(s) are you more
familiar with? Python doesn't force you into object orientation - you
can ignore it and just work with imperative code, if you prefer.

All the best!


More information about the Python-list mailing list