2

Iv'e been programming for 15 years now and I often read online that it seems like a lot of people will plan out their objects and how they interact and the data they need and that seems to shape the exposed interface. However, I find my brain works from usage backwards to the structure and data. I'm wondering if this is common and any pros/cons to this approach that anyone can think of, and what your mindset is when a new task is thrown your way. I want explore other ideas and approaches in mindset but I only know my mindset and I've been doing it so long. Is this what everyone does?

For example if I were to be tasked with making a stapler class I would write the usage that would make sense to me first and how I would want to use it and then fill in that usage. The first thing I do is open up notepad++ and type:

Stapler stapler = new Stapler(200);

stapler.Load(200);
stapler.Staple(papers);
stapler.UnJam();
int stapleCount = stapler.StaplerCount;

By looking at this it tells me that my stapler needs these functions/properties and I can infer what the parameters are by looking at them most of the time.

I seem to have an easier time thinking in code usage like this vs thinking about an abstract object and all it's functionality before writing any code. Writing out the usage often makes the abstract object real in my mind and is easier for me to grasp.

user441521
  • 454
  • 5
  • 14
  • 11
    You've just reinvented test-driven development! So yes, lots of people do that, and no, there is no consensus about whether this is the right way to program things. – Kilian Foth Jul 31 '14 at 12:57
  • Well, I wouldn't say reinvented. It's just the way I think. also I'm just looking for how others approach it. Interesting enough I've tried test development and I dislike it for some reason. For some reason just typing out pseudo code in notepad++ relates to me, but typing it out in a test and worrying more about the test doesn't. So it's not exactly TDD. Again though, this is just a discussion to get how people think about a task so I can learn. It's not about a right or wrong. – user441521 Jul 31 '14 at 13:00
  • 1
    possible duplicate of [If TDD is design, how do you know your TDD is well designed?](http://programmers.stackexchange.com/questions/234763/if-tdd-is-design-how-do-you-know-your-tdd-is-well-designed) – gnat Jul 31 '14 at 13:10
  • 2
    This though works poorly (in my experience) when working with more than one object. A stapler is good, but what about a trading platform or a cruise ship? – Telastyn Jul 31 '14 at 13:11
  • 1
    I do a lot of game development in my spare time so I often work with a lot of objects that need to interact. I do this same thing and it gets me to about maybe 75% usage that makes sense before I start actually coding. I don't always think of everything or type everything as I know I'll discover things at the time of needing them when I actually code and will need to fill in the gaps as I'm coding but the major layout generally seems to work for me. But Telastyn what do you do when you have many objects to design? What's your approach? Please make an answer instead of comment if you would. – user441521 Jul 31 '14 at 13:20
  • @user441521 - like you describe in your question. I focus on the dependencies between data, trying to slice across the slimmest (or least likely to change) dependencies. – Telastyn Jul 31 '14 at 14:11
  • 2
    I would not call it test-driven development. This type of development is much older than that. It is top-down development. – Frank Hileman Aug 07 '14 at 22:59
  • Or maybe you have reinvented [user story](http://en.wikipedia.org/wiki/User_story) instead. On the other hand, traditional (old-school) computer program is just "user story" applied to algorithms and data structures. Modern software engineering calls for more focus placed on human-computer interactions instead of algorithm-data-silicon interactions. – rwong Sep 28 '14 at 04:35

2 Answers2

2

Isn't your "usage" really just another form of use cases because your usage prototype, basically does what uses cases does which models the usage of objects. In that form, I think a lot of people make use case diagrams. Use-case diagrams derive from specifications document. So I guess that is within the planning process for objects. Only my perspective, however. I noticed it and wanted to chime in.

jax
  • 121
  • 3
1

Like others have commented, your approach is very TDD-like and pretty common. Although, not everyone takes to that way of writing code - it’s a matter of personal taste really. If you are looking for other styles to try then have a go at pair-programming with other developers that have differing styles to you and try them out for yourself.

If you are looking for a totally different approach to development - especially for large complex systems - consider having a look at SOA - usually pronounced “Soh-uhh". This is an non-functional approach to writing software systems (your style appears to be “functional") and the idea is to make everything anti-fragile - problems are isolated to their own areas of concern and is a bit like TDD for software architecture.

occasionalDev
  • 81
  • 3
  • I associate the term "SOA" with things like CORBA, service buses, message queues, and over-engineering in general, although I can see how the term might be applied to more "modern" (and lightweight) approaches like REST endpoints and MVC architecture. – Robert Harvey Jul 31 '14 at 16:48