Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Design and Architecture
  4. A questing about software design methodology

A questing about software design methodology

Scheduled Pinned Locked Moved Design and Architecture
designbusinesshelpquestion
8 Posts 6 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • P Offline
    P Offline
    popchecker
    wrote on last edited by
    #1

    I am planning to develop medium size library project for personal purpose. After documented the requirements, I designed an entity diagram. Now I am planning to define all classes, structs, enums and function body before coding the logic. As per my vision this method will help me to identify problems at the beginning, so that I can save the time to rewrite the logic. Is this a standard methodology? Is there any pre-defined method to do this? Thanks and regards, Thomas

    P M D 3 Replies Last reply
    0
    • P popchecker

      I am planning to develop medium size library project for personal purpose. After documented the requirements, I designed an entity diagram. Now I am planning to define all classes, structs, enums and function body before coding the logic. As per my vision this method will help me to identify problems at the beginning, so that I can save the time to rewrite the logic. Is this a standard methodology? Is there any pre-defined method to do this? Thanks and regards, Thomas

      P Offline
      P Offline
      Pete OHanlon
      wrote on last edited by
      #2

      Well, it's an interesting approach and an admirable one. Unfortunately, practical experience shows that the reality will fall short because requirements change as most projects and a rigid approach means that it is harder to adapt to these changes. I prefer, now, a more fluid approach such as TDD coupled with SOLID architecture, which makes it easier to work with isolated simple to use classes.

      I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be

      Forgive your enemies - it messes with their heads

      My blog | My articles | MoXAML PowerToys | Onyx

      P 1 Reply Last reply
      0
      • P Pete OHanlon

        Well, it's an interesting approach and an admirable one. Unfortunately, practical experience shows that the reality will fall short because requirements change as most projects and a rigid approach means that it is harder to adapt to these changes. I prefer, now, a more fluid approach such as TDD coupled with SOLID architecture, which makes it easier to work with isolated simple to use classes.

        I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be

        Forgive your enemies - it messes with their heads

        My blog | My articles | MoXAML PowerToys | Onyx

        P Offline
        P Offline
        popchecker
        wrote on last edited by
        #3

        But this is for my personal use. I am the coder and client So I am well aware of requirements. So are despite these problems, are you suggesting me to follow this mythology? Can you please suggest me any good read about this?

        P 1 Reply Last reply
        0
        • P popchecker

          But this is for my personal use. I am the coder and client So I am well aware of requirements. So are despite these problems, are you suggesting me to follow this mythology? Can you please suggest me any good read about this?

          P Offline
          P Offline
          Pete OHanlon
          wrote on last edited by
          #4

          popchecker wrote:

          So I am well aware of requirements.

          Are you - you're a much better person than me then :-D ? Even on personal projects, I've ended up changing requirements as things have evolved. There are plenty of articles here on Code Project and the web about TDD, I'd start off with general purpose articles if I were you.

          I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be

          Forgive your enemies - it messes with their heads

          My blog | My articles | MoXAML PowerToys | Onyx

          1 Reply Last reply
          0
          • P popchecker

            I am planning to develop medium size library project for personal purpose. After documented the requirements, I designed an entity diagram. Now I am planning to define all classes, structs, enums and function body before coding the logic. As per my vision this method will help me to identify problems at the beginning, so that I can save the time to rewrite the logic. Is this a standard methodology? Is there any pre-defined method to do this? Thanks and regards, Thomas

            M Offline
            M Offline
            Mycroft Holmes
            wrote on last edited by
            #5

            I salute your discipline, I have yet to create a design specification before the project is at least 80% done. A personal project tends to start as a data structure and flows naturally from there. If I screw up the structure I just fix redesign and move on. I use my personal development projects as learning experiences, usually built in a new tech/language so doing a bunch of design stuff before building it just seems silly. Data structures are pretty standard across all platforms but the internals of the app tend to be quite fluid. I am lucky in that even at work I can just build the solution and then create the doco after the fact (or not if I'm really lucky) after all my work projects are ALL POCs

            Never underestimate the power of human stupidity RAH

            M R 2 Replies Last reply
            0
            • P popchecker

              I am planning to develop medium size library project for personal purpose. After documented the requirements, I designed an entity diagram. Now I am planning to define all classes, structs, enums and function body before coding the logic. As per my vision this method will help me to identify problems at the beginning, so that I can save the time to rewrite the logic. Is this a standard methodology? Is there any pre-defined method to do this? Thanks and regards, Thomas

              D Offline
              D Offline
              David Skelly
              wrote on last edited by
              #6

              If you are doing this for learning purposes, then I would say this is not a bad idea. For someone who is learning OO programming, I think it can be useful to sit down and draw out the class structure first because it helps them learn to think in terms of objects and how they interact. Experienced programmers can get away without doing this because they have the experience to know what the rough structure of the classes should be, and they can evolve that as they go. Newbies don't have that depth of knowledge to draw on so they can easily end up with a huge ball of mud that sort of works but isn't maintainable. I don't think you need to go right down to the level of detailing the function bodies and so on, but sketching out a class diagram will help to get things clear in your mind before you start and make sure that you can see the wood for the trees when you find yourself buried in the coding phase. But don't be afraid to deviate from it when you are coding if you find a better way to do things once you get started. It's a guide to help clarify your thinking, not a rigid plan to be mindlessly obeyed. It depends on how experienced you are at designing and building this sort of application.

              1 Reply Last reply
              0
              • M Mycroft Holmes

                I salute your discipline, I have yet to create a design specification before the project is at least 80% done. A personal project tends to start as a data structure and flows naturally from there. If I screw up the structure I just fix redesign and move on. I use my personal development projects as learning experiences, usually built in a new tech/language so doing a bunch of design stuff before building it just seems silly. Data structures are pretty standard across all platforms but the internals of the app tend to be quite fluid. I am lucky in that even at work I can just build the solution and then create the doco after the fact (or not if I'm really lucky) after all my work projects are ALL POCs

                Never underestimate the power of human stupidity RAH

                M Offline
                M Offline
                Megidolaon
                wrote on last edited by
                #7

                This is about the same for me. For personal projects I tend to change design even more often as there is no one else involved I first have to consult with. So, while coding I end up noticing a different approach might be better after all, etc. and change the structure. When I learned programming they certainly did hammer into my brain that it's imperative to create detailed design sheets beforehand, but from my experience you should never go too much into detail unless required client side as it makes you far to inflexible. And once you started changing designs, you should wait to change the documentation until the project is done or otherwise you end up wasting time to redo the documentation every time you change something. I think it's best to design a concept and basic classes/methods beforehand and then fill in the rest when you really have coded it to not end up documentation a program that never came to be.

                1 Reply Last reply
                0
                • M Mycroft Holmes

                  I salute your discipline, I have yet to create a design specification before the project is at least 80% done. A personal project tends to start as a data structure and flows naturally from there. If I screw up the structure I just fix redesign and move on. I use my personal development projects as learning experiences, usually built in a new tech/language so doing a bunch of design stuff before building it just seems silly. Data structures are pretty standard across all platforms but the internals of the app tend to be quite fluid. I am lucky in that even at work I can just build the solution and then create the doco after the fact (or not if I'm really lucky) after all my work projects are ALL POCs

                  Never underestimate the power of human stupidity RAH

                  R Offline
                  R Offline
                  RobCroll
                  wrote on last edited by
                  #8

                  lol 80% done. I only laugh because personal or professional, that's probably the honest truth.

                  Architecture is extensible, code is minimal.

                  1 Reply Last reply
                  0
                  Reply
                  • Reply as topic
                  Log in to reply
                  • Oldest to Newest
                  • Newest to Oldest
                  • Most Votes


                  • Login

                  • Don't have an account? Register

                  • Login or register to search.
                  • First post
                    Last post
                  0
                  • Categories
                  • Recent
                  • Tags
                  • Popular
                  • World
                  • Users
                  • Groups