Jump to content
  • Advertisement
Sign in to follow this  
shurcool

On Source Code, Design and Implementation

This topic is 2176 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Today, the source code of a software project encodes *both* the design and the implementation of the app.

The design describes how the app looks, behaves and what it does (in theory).

The implementation is nothing more than a way of making the design a reality on a given platform. It uses known tools (CPU instructions arranged in a certain order, software libraries, programming languages, programming tools, etc.) to make the app real and working, rather than a design that is working only in someone's imagination.

Do you guys think it's a problem that source code encompasses both things? That they are inseparable, intertwined components?

I think so. Ideally, IMO, these two highly distinct concepts should be precisely that, distinct.

If I have a certain app that does something and looks a certain way, why should it matter what its implementation is? Why should it matter if I programmer A or programmer B wrote the implementation? Hell, the implementation might even be created by some sophisticated computer program.

The problem holding us back is... it's not easy. How do we represent design? Source code is a pretty good representation of implementation. But how do you represent design? It can reside in a designer's head, but that's not good enough. It can be scribbled on a piece of paper, or described in a lengthy design doc. But that's not good enough either, IMO. It has to be more dynamic, so that it can be linked up with a matching implementation and run on a computer/mobile device near you.

These are the right questions that we should be asking and trying to answer... IMO. Edited by shurcool

Share this post


Link to post
Share on other sites
Advertisement
Well I was going to "Report" your thread, so it can be moved to the General Programming forum. However, it seems that the "Report" function is for thread that are truly negative. With that said, this is not a Lounge question, but a General Programming forum question. And should be moved to that forum, where it would be better served.

Share this post


Link to post
Share on other sites
One could argue that the UI is the design and the code-behind (web or desktop) is the implementation of the design. You have software such as Windows Workflow Foundation that that tries to meld the design with the implementation. I'm sure by now that there is software that ties UML designs to the code itself. Basically presents a graphical tree/chart of your code and its flow. But it sounds like what you are describing is something similar to MVC (or similar paradigms).

Share this post


Link to post
Share on other sites
Fair enough. I didn't post it there because I thought it was too abstract for a forum like General Programming where real-world problems are being discussed, but I do want a programming-friendly audience to see it (hence GameDev.net).

Share this post


Link to post
Share on other sites

Fair enough. I didn't post it there because I thought it was too abstract for a forum like General Programming where real-world problems are being discussed, but I do want a programming-friendly audience to see it (hence GameDev.net).

No, this is definitely General Programming forum material. That forum now handles Software Engineering and Practical Programming issues.

Share this post


Link to post
Share on other sites

Today, the source code of a software project encodes *both* the design and the implementation of the app.

First, let's clarify exactly what you mean be "design," as that term can apply to a lot of things. Is the the UI design? Is it the workflow design? Is it the architectural design of the code? etc.

I'm going to assume you are aiming more at the UI design. I'd go with what Alpha_ProgDes said and say that what you want is probably something like a model-view-controller (MVC) design. It's entirely possible (and common) to design the UI (the view) using WYSIWYG or markup tools (i.e. without programming anything), implement a functional GUI-less back end that actually does all the work (the model) in some programming language, and glue the view and model together with a bit of code (the controller).

Share this post


Link to post
Share on other sites
There have been several attempts to address this, with varying degrees of success. Most notable is obviously the web model.

And other technologies also follow the markup model, such as WPF/silverlight, XUL and QML.

Share this post


Link to post
Share on other sites
If I have a certain app that does something and looks a certain way, why should it matter what its implementation is? Why should it matter if I programmer A or programmer B wrote the implementation? Hell, the implementation might even be created by some sophisticated computer program.[/quote]

You mean like how compilers generates machine code from human-readable source code? ;) In all seriousness, that's exactly what the whole concept of the separation between source code and machine code is for - just at a lower level than you're talking about.

So, what you're essentially proposing is some way to take the "design" of a program and produce a program from that, without worrying about what the implementation actually is, correct? Let's pretend that you've created some sophisticated design tool that lets designers specify a "design" and lets the computer figure out the "implementation". Since the "design" is now a direct specification of the program's look and behaviour, your "design" has now become the "implementation." So we're back at the beginning again.

I would say that if you're creating some sort of mechanism by which the design of a program is codified (which in my view is all that separates "design" from "ideas"), and the level of codification is sufficient that the machine can generate an implementation of the design for you, then all you're doing is creating a very high level programming language. In fact, I would say that a sufficiently formalized language intended for the design and specification of behaviour is the very definition of a programming language, no matter what medium it uses (textual in the case of traditional programming languages) and no matter what the compiled result is. Consequently, any design codified in that language is by definition "source code." Edited by Oberon_Command

Share this post


Link to post
Share on other sites

[quote name='shurcool' timestamp='1343002840' post='4962087']
Today, the source code of a software project encodes *both* the design and the implementation of the app.

First, let's clarify exactly what you mean be "design," as that term can apply to a lot of things. Is the the UI design? Is it the workflow design? Is it the architectural design of the code? etc.[/quote]
By design I really mean everything about how the app looks, feels, and behaves. This includes the UI, of course, but also the behaviour. When you click on a button, or swipe something, the displayed pixels change in some fashion. This is all design in this context, basically everything that's "the front of the scene."

The implementation is everything that's behind the scenes, like the language that was used, the widget toolkit, the rendering API, the choice of sorting algorithm, etc.

What if we found some way to cleanly separate these two things, such that the implementation could be interchanged while keeping the design untouched. So a user wouldn't even notice any change from their perspective (aside from potentially increased performance, etc.).

One potential advantage of this is that the implementation stuff could be improved separately from the design, and reused across multiple projects. Kinda like libraries, I suppose.

Oberon_Command made some very good points. I have to keep thinking about this. smile.png

Share this post


Link to post
Share on other sites

What if we found some way to cleanly separate these two things, such that the implementation could be interchanged while keeping the design untouched. So a user wouldn't even notice any change from their perspective (aside from potentially increased performance, etc.).

That's what the MVC architecture is all about. I don't know if I can go into much detail or not, so I won't go into too much, but take the company I work for, Sorenson Media, and our flagship product Squeeze, a video transcoding program. It's no secret we use Qt, but the key is that we are able to separate the GUI (everything you see and work with) from the transcoding engine (everything you don't see that actually transcodes the video). We can design the GUI, workflow, etc. in Qt designer. We can develop a separate GUI-less transcoding engine. Then it's just a matter of writing a little bit of glue code to connect the GUI to the transcoding engine, and walla, you have Squeeze Desktop. We just released version 8.5 recently, and while the GUI didn't change much, there were some significant backend changes made in the compression engine that allowed it to run up to 3x faster with some things. A user wouldn't realize the significant changes, because what they see and interact with is mostly the same. Alternatively, there were a few GUI and workflow changes that didn't require us to rewrite the engine, as they're separated.

Another benefit is that we can use the compression engine in other products of ours, like our cloud server, without booting up a GUI version of Squeeze Desktop.

Separating the front-end (what the user sees and interacts with) and the back-end (what actually does the work) is generally good practice, and there are several patterns and design architectures created specifically with that goal in mind. ChaosEngine noted some of the technologies that strive to make this easy.

I don't know how familiar you are with the MVC software design, but if you're not too familiar with it I suggest trying to get familiar with it by creating a program with C# + WPF or C++ + Qt (or whatever combo you may choose).

I think the really interesting question is what alternatives to the MVC software design exist, and what are good practices for separating the front-end from the back-end.

I suppose how you represent and design the front-end is a good enough question though. My answer would be: we can represent design with flowcharts documenting workflows, WYSIWYG editors for actual design and creating the GUI, markup languages for defining layout, etc. Then it's just a matter of gluing this to the code (in Qt, this is done with signals and slots), more or less.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!