7

I know a lot about programming syntactically. What I am unsure is about how should I go to build a software from scratch. How should be the objects be designed and how should they interact with each other.

To learn how good softwares are written I have tried to read code of some good open source softwares but could not get a slightes of idea, how they are designed as there is no availble documentation available regarding the code.

I want to become a more skilled programmer but I could not go any further, I am well versed in programming but now i am stuck as I have no way to go forward.

Please guide about how should I learn the software design and what should be next to improve the skills.

P.S : I am a hobbiest programmer, i have never worked in a software house neither am i looking forward to it.

Ben Aaronson
  • 6,883
  • 1
  • 30
  • 30
S. A. Malik
  • 181
  • 1
  • 1
  • 4
  • Look for "modularity" and "dependency injection". – Jean-Philippe Leclerc Apr 08 '13 at 19:44
  • 3
    Look for "Gang of Four" and/or software patterns and practices. – Jon Raynor Apr 08 '13 at 20:09
  • 4
    Just like any other skill: practice. Design (and write) little programs until the design is good, then get a little bigger; repeat. – Telastyn Apr 08 '13 at 21:27
  • Search for Object Oriented Programming and look for Agile and Software Development – Mushy Apr 08 '13 at 21:32
  • 1
    @Jean-PhilippeLeclerc It might be too soon for the OP to read about dependency injection. It would confuse him rather than help him at this time. – marco-fiset Apr 08 '13 at 23:26
  • @marco-fiset Dependency injection is just a scary word to describe a very simple concept. I think that anyone at almost any level of knowledge can understand how it works and why it reduces coupling between classes. I may be wrong tho. – Jean-Philippe Leclerc Apr 09 '13 at 02:20
  • 1
    @Jean-PhilippeLeclerc It's a concept I perfectly understand now, but in the beginning I did not understand how it could be beneficial. It's like everything in programming, once you understand it, it becomes very simple. – marco-fiset Apr 09 '13 at 02:51
  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see [ask] – gnat Apr 09 '13 at 05:56
  • @robert Harvey Thanks for a -ive, but i have properly searched before posting and could not find any questions. The question shown as dubplicate is a lot different from what i have asked. – S. A. Malik Apr 09 '13 at 17:46

2 Answers2

4

Start building small "completable" projects from scratch using your existing knowledge on your own as side "projects" ..just make them up. Then refine / refactor the design by identifying and implementing Patterns / "good principles" you've learned from your reading / learning. Once the project has been completed and "refactored thuroughly", Do it again...

There are definitely some architectural "starting points" like keeping various "code layers" separate (DB access layer, Biz Logic layer, etc..). As well as trying to identify where "Interfaces" can be used so you can "extract" their "implementations" and begin introducing some kind of Dependency Injection framework... But that can be done during later passes of your "refactoring" efforts (if that's a path you even want to go down).

I would say there's no "silver bullet" or "this is how you do it" because projects vary so greatly. You can watch pod casts and read books, which all help becoming an expert, but until you are able to implement what you've learned, there's still a pretty large gap, and the only way to implement what you've learned is to either do it and learn from your own mistakes, or find a good mentor who can teach you what they've learned from their mistakes..

"Just having the map doesn't get you to your destination"

Brandon
  • 4,555
  • 19
  • 21
hanzolo
  • 3,111
  • 19
  • 21
4

You are basically asking how to design programs. It turns out there is a book which teaches you that, and it is called … How to Design Programs (aka HtDP). It teaches you, well, how to design programs. And it does this by giving you recipes to follow for how to analyze problems, solve them, transform them into algorithms and further into working programs.

Note that "recipe" is basically another word for "program", so in other words, the book teaches you programs for humans to run in their heads in order to generate programs to be executed by computers. How cool is that? :-)

The authors are currently working on a draft for a second edition of HtDP, which you might want to read instead of the first edition. The material about imperative programming has been removed, and is going to be covered in the as-of-yet unwritten second volume How to Design Components, but you can read those missing chapters from the first edition.

Note that HtDP assumes no programming knowledge and is targeted at high school students. But don't let that stop you: it just means that you'll probably be able to finish some early chapters faster, but I don't think you will be bored.

Concrete Abstractions is also a good read along similar veins. Like HtDP, it doesn't assume any programming knowledge.

Another book that you might hear mentioned is Structure and Interpretation of Computer Programs aka SICP. It is one of the greatest programming books ever written, and again, it doesn't assume any programming knowledge.

It is, however, geared to complete newbies who study at MIT. And so, while it does not assume any programming knowledge, it does assume quite a bit of domain knowledge, e.g. in the fields of electrical engineering, physics and math. Note: these have nothing to do with the concepts being taught, they are just needed to understand the exercises and examples. So, it might be better to read HtDP or Concrete Abstractions first, and then read SICP.

Jörg W Mittag
  • 101,921
  • 24
  • 218
  • 318