A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Seperate platform-dependent code from your application logic code.
Your app logic code should be fairly simple and exploit as small subset of language and library features as possible. Your platform-dependent code should be formed into a few libraries with simple and well-specified APIs
To make sure you have seperated them well, you can start development with more then one target platform.
Then, for each platform you want to port, you need to write library implementation for that platform; if neccessary, write a compiler for the app logic language into the target platform.
Tuesday, June 12, 2007
What sort of user interface(s) will your application have? Which platforms will it need to run on?
There is a difference between "must run on Windows and OS X" and "must run on Apache and IIS" or "must run on IE, Firefox and Safari".
Tuesday, June 12, 2007
Today, I think that the easier way to "assure" portability is two fold: first adhere to a managed code environment like .Net (which is today portable thanks to the Mono project, www.mono-project.org) or Java for the server side code. In th client side, use a web based interface with Ajax or something like that.
if you are talking about a desktop appliction, then you can still use .net (developing user interfaces in java is just insane), but expect some portability problems because user interfaces tends to be too platform dependant (and Mono is not 100% ready here).
if you must use a non managed code, like C or C++, then you should create a kind of platform abstraction layer that provides you all the elements that could be platform dependant,but this is going to bee a huge work and very likely you will end up re-inventing the wheel.
I must, respectfully mind you, disagree with everything Pablo stated. I almost agreed with the third paragraph up until
"...but this is going to bee a huge work and very likely you will end up re-inventing the wheel."
Speaking as an embedded developer that supports DOS, Windows, Linux, Mac and some platforms that are made in house are not known outside of internal manufacturing this could not be further from the truth. All about planning, designing, and knowledge of the problem along with the domains they reside.
The problem with automatically assuming one tool/one language/one VM* to bind them all is that you eventually learn that a VM not only abstracts out those details nobody can be bothered with learning in today's day and age about an actual platform but also those gotcha's that make all those platforms different. I believe the host of this site, Joel himself, has such an essay covering exactly that which I mention here in my reply.
Briefly: J2EE != J2SE != J2ME. Not to bash VM's like Java. I believe Ruby is extremely popular these days and quite the rave, cross platform, joy to use, etc. Try running a script written in ruby that accepts feedback or configuration from a user and you'll soon see it chokes on something simple like / or \ for file paths...And those are on the two most widely known systems that are used en masse.
So the answer to the OP has already been given: Abstract out the platform dependent code and make the core application program to an interface. Works regardless if you are doing procedural, modular, generic, or OOP.
The most important piece of information about supporting platforms and ensuring portability have jack to do with programming and more to do with knowing the differences between the platforms themselves and the purpose that the platform exists. In short the key to design is in leveraging domain knowledge properly in the problem space being addressed.
*I picked on VM's but it doesn't stop there. Completely jumping off tangent: Your last programming solution and the lessons learned from implementing it may have absolutely no fit for the next project in line but many designers/developers will try to forge ahead because the last time was a success. Point is I'm not bashing .NET or Java. A tool is a tool is a tool in the hands of the skilled nothing more.
I could agree with you *IF* I had a endless suply of resources and time *OR¨* my application were rather simple *OR* it required a small subset of the resources provided by a plaform (say, jut access a device)
In almost any other case, for a complex application that need acces to diverse local resources and also to an user interface, it is almost absolutly impossible to abstract an aplication entirely from the platform . . . unles you create your own VM, because that "interface" as you call it, well end up been more than a interface. You will requere lots of intefaces to abstract from devices, error, files, memory management, user interfaces, process creation, inter-process comunication . . .
I tried a couple of times and both cases I gave up a picked a VM. Oh, yes it was really fun and educative.
However, I think that nowdays it is a waste of time as there are some good VN out there as JVM or .Net's VM (I can't recall its name right now)
By the way, running an script on top of a scripting engine is basically the same: the script is a managed code inside the engine that guess what? it abstracts the script from the platform.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz