10 replies to this topic

[psepheroth]

Hello all.
I'm just an amateur programmer learning design patterns.
I recently get acquainted to some patterns. However, this question pops in my mind.
What if the program is just simple? Would design pattern still apply? Will design pattern always apply to "every" code you make?
Say for example, I'm trying to make a code that will determine if the string is a palindrome or not.

BOOL isThisPalindrome(char *s)

Something like that, would design pattern be needed?
Please enlighten me.

[gregwarner]

It's a good idea to practice good design strategy, no matter how simple of a program you write. True, you might be able to type out a quick one-function program just to fulfill an assignment for class, and while it might work, if you skip the proper design work, you might end up with an algorithm with complexity O(n^2) rather than something better like O(n log n), just for example. It also helps to avoid errors. So I would recommend that you use all the tools available to you and practice designing good algorithms.

What sort of design patterns were you thinking of?

[psepheroth]

gregwarner said:

It's a good idea to practice good design strategy, no matter how simple of a program you write. True, you might be able to type out a quick one-function program just to fulfill an assignment for class, and while it might work, if you skip the proper design work, you might end up with an algorithm with complexity O(n^2) rather than something better like O(n log n), just for example. It also helps to avoid errors. So I would recommend that you use all the tools available to you and practice designing good algorithms.

What sort of design patterns were you thinking of?

I haven't thought of any design pattern yet. Currently studying for that.
By the way, from your statement, I understand that there is a need for d.patterns. But what pattern could I have use for simple program like

BOOL isThisPalindrome(char *s)

?

[gregwarner]

You don't need anything too complex just to check for a palindrome. I would just come up with a robust algorithm which detects palindromes, and draw a flowchart to visualize its process, making sure it is accurate for all cases, then try to calculate the efficiency of your algorithm.

[psepheroth]

gregwarner said:

You don't need anything too complex just to check for a palindrome. I would just come up with a robust algorithm which detects palindromes, and draw a flowchart to visualize its process, making sure it is accurate for all cases, then try to calculate the efficiency of your algorithm.

Yes. I understand. But what design pattern did you use on your palindrome?

[gregwarner]

That's too far back for me to remember. :) I think that was still back when I was extremely unskilled.

[WingedPanther]

You generally don't use a design pattern for a palindrome checker. Design patterns are generally meant for controlling how hundreds of classes will interact. A palindrome checker doesn't even need ONE class, so design patterns doesn't really apply.

[psepheroth]

WingedPanther said:

You generally don't use a design pattern for a palindrome checker. Design patterns are generally meant for controlling how hundreds of classes will interact. A palindrome checker doesn't even need ONE class, so design patterns doesn't really apply.

Thanks WingedPanther.

[lespauled]

Consider Design Patterns as a tool. There are many different design patterns for a lot of different situations. With that said, there is a time and place for everything. There are some small applications that do NOT need design patterns. Like any other tool, they are great for certain project, not really helpful in others.

[fayyazlodhi]

Like WP already explained i would like to elaborate a little,

Design pattern, or OOD or Agile / Extreme programming any of such things are strategy's for a software project.

There are many aspects that make a software a project but let me point out the most critical ones:

1. Scale: This can refer to say a hundred classes interacting with each other. Or 50 different libraries interaction with each other. It means there is a lot to code and a lot of which is reused. HOW one choose to divide the large project into classes is the critical decision which latter impacts the size, reuse and scale of code.

A good example would be a race game where one could code an entire screen including car, track and every thing and move from there. But you really run into problems latter for e.g. when you need nearly the same car with slightly different behavior but not the back ground. With a proper design (no matter what approach or pattern is used), you might code a separate car, separate track, then Perhaps a UI which interacts with a car when needed etc.

2. Code Maintenance: When you get into software industry you would realize that it is very rare to write code from scratch. Most of the times it is a pre written product which has been seen and modified by a number of developers over the course of time. A good design and neat code is easier for a new maintainer to reuse and understand. If you have to rewrite or extract the same functionality from a large program many times, you might be cursing the initial designer to have made it a separate class or function that can easily be reused.

3. Time to deliver a working feature: Wrongly perceived design would result in more code to write, debug and maintain. A project done with the right design strategy has more chances of being completed in time, easier to fix bugs and predictable effort to add features to.

Hope that helps.

[psepheroth]

Many thanks guys. It's getting more clearer now. :) Thanks :)