Is it a bad idea to design and develop a python applications backend and then once finished try to apply a GUI to it?_问答_开发者

Is it better to do it all at once? I'm very new to wxPython and I'm thinking it would be better to write the program in a way familiar to me, then apply the wxPython gui to it after I'm satisfied with the overall design of the app开发者_开发技巧. Any advice?

This is a viable approach. In fact, some programmers use it for the advantages it brings:

Modular non-GUI code can then be tied in with different GUIs, not just a single library
It can also be used for a command-line application (or a batch interface to a GUI one)
It can be reused for a web application
And most importantly: it can make unit-testing of the code easier.

However keep in mind that it requires some careful design. You'll want your "logic code" to be free from GUI constraints, and sometimes it is difficult (especially when the code relies on GUI idioms like an event loop).

That depends on the problem domain. An image processing tool would be rather difficult to implement without reference to a GUI. For most apps, though, I would argue strongly in favour of separating the two parts. It is much, much easier to develop, test and evolve a UI-free back-end. The gains will vastly outweigh the cost of defining a clean API between the front and back end. In fact, the process of defining the API will yield a better design overall.

Separation of the user interface from the engine code is the unixy way to do it and there's a lot of merit to doing it that way. It results in modular re-usable programs and code that can play nicely with other programs and fit into a larger tool chain.

Having said that, such an approach tends to discount the value of creating a really usable UI experience. It's very difficult and rare for a program's internal model to match the user model when you design your program's functionality first and then the user interface later. As a result, you need to impedance-match the two sides after creating them independently. This results in either creating a compromise in usability (your ui becomes nothing more than a front-end to the command line switches your program takes) or a large glue layer between the UI and the core program which tends to be messy and buggy.

If your program is primarily designed to be run through a user interface interactively with a user, then it probably makes sense to design the user interface in parallel with your actual functionality.

So:

it would be better to write the program in a way familiar to me, then apply the wxPython gui to it after I'm satisfied with the overall design of the app

If your UI is the main means of operating your program, then that UI is part of the program design. Not something to be painted over the program when its done.

IMHO, that would rather be a better idea. To keep the underlying business logic not tied down to the UI is a better approach that we can worry more about the underlying logic than bogging down too much about the interface.

At the same time, it is also important to have some basic design for your interface so that it helps you have an idea about what kind of inputs and outputs are involved, and making the underlying logic support a wide range of inputs/outputs or simply wide range of interfaces.

Since you are new to GUI programming, your approach is perfectly valid. It will likely result in a less than optimal UI, but that's OK for now. And in fact, there are some very successful multi-million dollar commercial projects that are built this way.

Arguably a better approach is to first design the UI since that is the most important part. After that is completel you can then create a back-end that can support that UI. This approach still results in separate front- and back-ends but puts the emphasis on the needs of the user, where it should be.

What level of interactivity do you need? If you need rich feedback and interaction, then you need an OO program model, then you can ad the GUI on top of the objects.

If you just have filters and functions (no real feedback, or just a results window) than a library or component model would be better.

Either way, you are better off coding your logic separate to the GUI, so you can test it more easily.

If you're used to a more command line approach, this would be a bad idea. Responding to user input is a completely different paradigm, and you're not likely to get it right the first time.

If you're just talking about the difference between wxPython and another GUI, don't worry about it.