views:

109

answers:

3

I read a lot of books about how to code right and usually they are talking about all these techniques from a point of view I can't understand.

E.g. lets consider the singleton pattern:

I'm restricting so the class can only be instantiated once, but since it's only me creating the application, if I know that the class only should be instantiated once, then why would I create it a second time?

It sounds like I'm securing against myself.

I feel like missing the big picture.

What is my main goal when coding an application?

How should I think?

Thanks.

+6  A: 

Make it work, make it work right, make it work fast.

Most patterns introduce complexity as one price to using them. Do not add patterns if you do not need them.

In the case of singleton - if you don't have to restrict the class to one instance (and when do you really need to), don't turn it into a singleton. It only makes your code more complex and difficult to understand.

Oded
I had to upvote you. **"Do not add patters if you do not need them."** <-- Should emphasis that :-)
pst
@pst - emphasis added ;)
Oded
+1 I would actually add "do not optimize it if you don't need it." Most of the code in any project is not executed often enough for its optimization to produce any measureable difference. Optimization also introduces complexity, so one should verify that that price is actually paid back.
Péter Török
+3  A: 
  1. Because 2 years down the road, you will forget that it was supposed to be a singleton and violate that when updating the code. Remember that extremely high (IIRC >70%) of effort is spent maintaining existing code, not writing new one.

  2. Using the pattern will allow you to train yourself for when you do NOT work as a part of 1-man team. At which point other people will not know what was supposed to be a singleton.

DVK
+1 for point 2. It's all about intent. It's like justifying writing an essay at the level of a kindergarten student because you'll be the only one reading it. You need to write clearly; clarity is a sign of clear and intentional writing, and is much more valuable then writing that -just- get's it's points across.
Pierreten
+1  A: 

"Creating a product that works" may be the main goal. But it's about as helpful as "creating a piece of music that just rocks" is for an aspiring composer. The main question is "how do I create a product that works" - which is pretty much about skill.

Programming is such a wide field that you can't just pick a few "fundamental laws" to focus on. There may be 1000 or 10000 separate considerations, each of which is important in particular context, from particular point of view. The only way to learn the skill is to work, write code (this also includes making mistakes), read other peoples' code, read (often contradicting) opinions and ideas from books and web etc. Do that regularly for 10-20 years and you'll get good.

For instance, whether not to use a singleton is about making a trade-off between initial complexity (using statically referenced singletons is slightly simpler than carrying a reference around) vs. future malleability (you may find you've "painted yourself into a corner" later on). Some people are dogmatic about avoiding globals ("singletons are evil"), and even though it may be a good rule of thumb in general, globals and singletons do have their uses. For example, Java's System class is essentially a global singleton.

Joonas Pulakka