[AdamSpeight2008]

What are your rationale behind which design approach you use?

This post has been edited by AdamSpeight2008: 24 February 2012 - 08:21 PM

[CharlieMay]

I actually do a lot of database work so a lot of what I start with is what information I want to store and then I work on normalizing it.

Once the data storage is designed I start working on functions that I've written and can re-use or need to write. Now though, more and more, I look at creating various classes to handle the objects.

Then it's on to the GUI although I must admit, I'm not real strong with encompassing everything in objects so I still find myself going back and tweaking them. Sadly enough, this part of the process still seems to dictate how some of those classes are designed and the end result still leaves be knowing that I have room for improvement.

I guess my rationale as to why the database first is that the data is the important factor in the end result and as long as I have the proper data, I can write code to manipulate it as I see fit.

Since you started this topic, and anyone who's been here for a bit knows you don't start with a GUI, I would personally like to hear your response to your topic Adam. You should also edit your post and include what type of program you typically are involved in. I know not everyone has certain type but there are people that do a lot with graphics, math etc... and I guess I feel like that could be a huge factor in where each person starts their projects.

This post has been edited by CharlieMay: 24 February 2012 - 08:49 PM

[janne_panne]

I might design the GUI first but not do it first. I find GUI design lots of fun so when I start doing new application, I think about the GUI first just to get me motivated. It also helps figuring out some features I might need later on.

But what I code first is usually the Models in MVVM application as far as I can think of. At the same time with models I create the data access stuff, at least to a basic level where the select/insert works. Then comes the View and ViewModel and while doing them I update my data access stuff with more advanced queries when I need them. Models might also be affected by some minor changes if I hadn't thought about something when doing them.

[woodjom]

I never design the GUI first, i always work on the library of operations first and then it makes attaching the GUI to the library alot easier.

[eker676]

I never design the gui first. However if I know the program is going to have a gui I design it a bit differently than if it was going to be a straight console app.

[code_m]

woodjom, on 25 February 2012 - 10:09 AM, said:

I never design the GUI first, i always work on the library of operations first and then it makes attaching the GUI to the library alot easier.

I agree whole-heartedly. I have tried to do "GUI First", but in the end my backend was completely un-readable and full of bugs.

[AdamSpeight2008]

I write my solutions in a GUI-agnostic way and also built of sub-components. This makes the engineering and coding a lot simpler. Each component only works on the parameter arguments passing into the components methods (be that a Function, Sub or Property) and the internal states that it keeps. Scope and Visibility is as narrow as possible, so the only way to interact with is via the methods it provides. Thus no reaching in from the outside. Changes that need to observed on the outside is due via Events. Errors are often conveyed via custom exception class. Also I like to wrap Numeric types in a Wrapper class to express the meaning and context of the value, so type-safety checks can happen a compile-time

Some may think this is a lot to keep track of, so the solution is made up of sub-projects and various namespaces.
So the various sub-projects, which build into separate DLLs and EXEs

• Interfaces
  
• Base Classes
  
• Exceptions
  
• Component Objects
  
• GUI

The first GUI is often Console-based as it makes for rapid prototyping and testing of the design.

When beginners learn by doing GUI applications they tend to do the following.
Example: Convert Celsius to Fahrenheit

Spoiler

   Label1.Text = ( Textbox1.Text * (9/5) + 32)
 

Everything is a control. They only think in terms of controls.
Plus they think that what they see on screen (Numbers) is what the computer program recognizes it as a number, and then get confused when the run-time complains at them.
What the language can do, is a tribe they don't even know exists. Don't start me on the lazy naming of the Controls.

Spoiler

 Function CtoF(C As Double) As Double
   Return C * (9/5) + 32
 End Function

This is a bit better since it separates out the conversion function from the GUI controls. It only acts on the parameter it accepts. To me it has a problem, which is it can accept any Double, by that one that represents something that is a temperature.

This is what I'd write.

Spoiler

Create base-class the represents the concept or idea of Temperature. (Temperature_Base)
Create class that inherits from it (Temperature_Base) for both Celsius and Fahrenheit.

 Function ConvertCtoF( C As Celsius ) As  Fahrenheit 
   Return New  Fahrenheit( (C.Value  * (9 /5)) + 32)
 End Function
 

Now the Conversion function only works on Celsius objects.
Imagine if NASA and it contractors used this approach when it wrote the code for the Mars Polar Lander.

So the core of the problem (temperature conversion) is solved. Building a GUI especially a Windows Forms application on top of the framework components I've created is simple. You want to change to design of the GUI, does that effect how the conversion works?
Of course it doesn't.

DIC is full of examples of bad designs and coding horrors because GUI first design approach.

This post has been edited by AdamSpeight2008: 25 February 2012 - 06:55 PM

[CharlieMay]

While I don't disagree with you Adam, one of the reasons I believe this happens (using controls and their properties instead of creating functions,classes, interfaces, etc... as you're describing) is because since its inception, the VB language (and we're going back to actual VB) has always been marketed as a R.A.D. Language. The fact that you can do this makes it easy to quickly provide a solution. Yes there are mis-interpretations that the compiler produces that causes many programmers to start removing their hair at the follicles but the fact remains that it is inherent in the language and by nature we can all be kind of lazy

Now, the problem with this is as you stated, you do a lot to ensure that you keep the scope and visibility to a minimum. By default, and someone correct me if I'm wrong because as I understand it, VB.Net creates everything is such a wide scope that it takes these extra steps to limit it. So for the average user, VB.Net is still a R.A.D. Language UNLESS you want to tighten it up which takes more time.

Not to mention, classes still teach the use of the controls for the information, so it takes someone with a little extra interest in providing secure, manageable code to move out of this "school" of thought.

This post has been edited by CharlieMay: 25 February 2012 - 07:16 PM

[farrell2k]

I am definitely not a good programmer, so take my advice with a grain of salt. I never write the gui first. I like to implement all of the backend code. the tailor the gui to that, I find it's just easier.

[pryogene]

I answered yes. I don't build my GUI first, but I do design it. I find that having something that looks even borderline like what I should be ending up with allows me to generate a list of functions it should perform, and relevant pseudocode if the mood takes me.

If there's no GUI, then I actually find myself listing example outputs; Which has the same effect.

[BobRodes]

I always work with a GUI prototype until I have an agreement on what the application is going to do and how it is going to work. It's important to me to get paid for what I do, and the people who are paying typically care a lot more about whether the program will meet their business requirements and how easy it is to use than they do about the implementation details. They just want those to be well-constructed or some other such vagary. I generally don't do any more work on the data structure than is necessary to support prototyping until we have an agreement on what they are going to be paying for.

No sense building database architecture only to have someone explain (once they fit you into their busy schedule six months into the project) that we have the business rules all wrong, and we find that we have to redesign our database to accommodate the correct ones.

This post has been edited by BobRodes: 09 May 2012 - 11:57 AM

[DarenR]

I always do the gui 1st so that I can get it approved in its entirety 1st. Most fo the ceo's i deal with dont care abouit the back end but really care about the front end and when I do the gui 1st I can get their input quickly thus know what I have to put in the back end.

[woodjom]

BobRodes, on 09 May 2012 - 01:48 PM, said:

I always work with a GUI prototype until I have an agreement on what the application is going to do and how it is going to work. It's important to me to get paid for what I do, and the people who are paying typically care a lot more about whether the program will meet their business requirements and how easy it is to use than they do about the implementation details. They just want those to be well-constructed or some other such vagary. I generally don't do any more work on the data structure than is necessary to support prototyping until we have an agreement on what they are going to be paying for.

No sense building database architecture only to have someone explain (once they fit you into their busy schedule six months into the project) that we have the business rules all wrong, and we find that we have to redesign our database to accommodate the correct ones.

There is actually no sense in spending an exorbidant amount of time developing (prototype) the GUI if all they are going to do is throw your knowledgeable design in the trash and then have you redesign based on their needs, that they of course failed to express during the "discovery phase"

Yes I had that happen to me once, and i never make the same mistake twice, so now i spend maybe 16hrs of a project on prototyping the GUI and the majority of the project is spent on content and design and then i spend usually the last 1/3, usually last 1/4, of the project on GUI LAF (look and feel) with the functionality already attached just waiting on client making decisions on placement of controls and how menus are designed.

[BobRodes]

woodjom, on 09 May 2012 - 03:04 PM, said:

BobRodes, on 09 May 2012 - 01:48 PM, said:

I always work with a GUI prototype until I have an agreement on what the application is going to do and how it is going to work. It's important to me to get paid for what I do, and the people who are paying typically care a lot more about whether the program will meet their business requirements and how easy it is to use than they do about the implementation details. They just want those to be well-constructed or some other such vagary. I generally don't do any more work on the data structure than is necessary to support prototyping until we have an agreement on what they are going to be paying for.

No sense building database architecture only to have someone explain (once they fit you into their busy schedule six months into the project) that we have the business rules all wrong, and we find that we have to redesign our database to accommodate the correct ones.

There is actually no sense in spending an exorbidant amount of time developing (prototype) the GUI if all they are going to do is throw your knowledgeable design in the trash and then have you redesign based on their needs, that they of course failed to express during the "discovery phase"

Yes I had that happen to me once, and i never make the same mistake twice, so now i spend maybe 16hrs of a project on prototyping the GUI and the majority of the project is spent on content and design and then i spend usually the last 1/3, usually last 1/4, of the project on GUI LAF (look and feel) with the functionality already attached just waiting on client making decisions on placement of controls and how menus are designed.

I don't think there's any sense spending an "exorbitant" amount of time doing anything. It takes as long as it takes to get signoff on the requirements, so if it can get done in maybe 16 hours, well and good. If it takes 200 hours, well and good. How long it takes really depends on the size of the problem domain.

As far as I'm concerned, and this is the point I'm making, GUI prototypes often uncover hidden requirements. People look at it and say no, that's not quite what I'm looking for, I need one of these, and so on. That's why I start with the GUI, although of course I really start with a problem statement.

My point is that including prototyping in the "discovery phase" leads to better discovery. A visual representation of an answer to the question "what do you want to do" seems to be effective in refining that answer.

It would seem that you don't disagree, given that you appear to be saying that you design the GUI first, whether you refine it later or not.

This post has been edited by BobRodes: 10 May 2012 - 06:23 AM

[woodjom]

And there in lies the defining reason. A well defined scope, on paper of course , will make GUI design alot easier and less cumbersome on the development time.

In the past i have dealt with developer that make the car look like a Corvette even though when put on the road performs like a Pinto. Which means they spent 80% of their time on the GUI and 20% of their time on the content of the development. Which is "bass ackwards" and leads to developers getting a bad rapoire cause of a few "idgiots"

I just dont put alot of time or effort in developing the interface as it is fluid and can be easily changed with a few mouse clicks, drag-and-drop, or ultimately the delete. The content of the software is a different point in case and is almost always the opposite of the GUI.

This post has been edited by woodjom: 10 May 2012 - 07:13 AM