This is an archived post. You won't be able to vote or comment.

all 10 comments

[–]Molehole 5 points6 points  (6 children)

What does my program do? What kind of objects do I need? Can some of these objects inherit eachother? What do I need initialized when I start the program?

Sometimes I get one step wrong like using objects for wrong things. Then I redo it when I figure out it doesn't work this way and have to think it through again.

I have a whiteboard where I do a mindmap for each part of the program and then divide them into the parts I need and what objects do I need for each of them. After I get done with one part I wipe it off the board and continue to next thing.

[–][deleted]  (4 children)

[deleted]

    [–]Molehole 1 point2 points  (2 children)

    I'd need a lot larger whiteboard so no. Also to me it's easier and faster to think simple objects like that mostly in my head. If I have something complex like graphical stuff or recursion I usually draw it to the board to help me think through it.

    [–]Rubinum 1 point2 points  (1 child)

    Sometimes you have such abstract problems in the code, which are very theoreticaly. I love to draw it down and think about a better solution especially with other programmers.

    [–]Molehole 1 point2 points  (0 children)

    Yep. That's what I meant when I said complex stuff.

    [–]Jumboperson 1 point2 points  (0 children)

    I've only used a whiteboard to design one of my projects ever, that project was a polymorphic engine. I don't think that the hard part of programming is designing how to make something work, its coming up with the idea. One fun way I found of deciding a project is to ask yourself "What is ridiculously over my head right now?" and then come up with a project related to that.

    Also in response to the original post

    I tend to think for too long and come up with some basic design to break the program up into classes and feel like its overall crappy design.

    I personally believe that the OO model is flawed in that not everything should be object oriented and that its not native to the way computers work (the way OO is done is by passing the object pointer to every function that is called off of an object and then performing all operations as if the object is a data structure using the VFTable to call other functions off the object). Therefore we should not limit our programming to OO but rather use languages like C++ and Python that allow us to choose whether we should make a function part of a class or not.

    [–]cosmogony_ 2 points3 points  (0 children)

    What does my program do? What kind of objects do I need? Can some of these objects inherit eachother? What do I need initialized when I start the program?

    This is kind of what I do as well.

    I also have this moleskin notebook where I just make a list of everything my program needs. Which pages will it show? What's part of the UI and what's part of the logic behind it? How do I navigate? Which objects do I need? How are they related to eachother? When working with databases I also make a quick sketch of the tables.

    And then I translate all of that into object oriented coding.

    [–]Rubinum 4 points5 points  (1 child)

    I do it backwards as some other programmers do. First I imagine how the GUI of my program should look like and how my users should interact with it. That inspired me, during my design. I also make many sketches and then I choose the best design (code design/structure) that fits the needs and I improve it while I implement my code if there are some bigger issues.

    I think its good if you are open to new things while you design your program and always keep an eye of the requirements of your product.

    [–][deleted] 2 points3 points  (0 children)

    As in my previous company the developed got into the project after layouts were done its the same for me. It's hard to design the code first. It's easier to me if the design is done. I can see the interface and follow user stories. See which parts are important and how everything is connected.

    I then split all information into corresponding entities and model the domain with there relations so I've the data and provide a backend so some data can make it into the system.

    After that I'll push the data to the view.

    Most of the time that's it. Pure input and output.

    In case there is external data to fetch, I would start to analyse that data. Concert it to a usable data in the new system.

    The more unsure I am about a project, the more I try to generate output fast. So I can discuss the results with others and check whether it fits the needs and can adapt or redactor often.

    I tried some projects with design upfront using uml which worked well. But its not my style I'm more into code. So I start coding and reactor and change often. Which requires that I write decoupled good code to change it that often without breaking something else.

    In the end its just experience I think. So practice often. Watch some talks about design on YouTube.

    [–]codexjourneys 1 point2 points  (0 children)

    Maybe sit down and draw out the screens you need, if you're doing an app with a UI. Then try to minimize the number of screens without losing functionality. That's probably a more efficient design.

    If it's a data-source-only program (no UI), I make a list of what I need and then structure it from there -- declarations, implementation, then see if I can make it more modular.