2 added 4 characters in body
source | link

Your economics professor is absolutely correct.

Software Design Patterns are primarily a way for experienced software developers to communicate with each other. They are a shorthand for established solutions to known problems.

But they should only be used by people who understand how to solve the problem without the pattern, or have come up with a similar pattern on their own. Otherwise, they will have the same problem as the copy/paste coder; they will have code, but they won't understand how it works, and therefore will be unable to troubleshoot it.

Also, many of the design patterns are enterprise patterns, patterns that are intended to be used in large, corporate software systems. If you learn the wonders of the Inversion of Control container, you will want to use it in every program you write, even though most programs don't actually need it (there are better ways to inject your dependencies in smaller programs, way that don't needrequire an IoC container).

Learn the patterns. Understand the patterns, and their appropriate use. Know how to solve the same problem without the pattern (all software patterns are abstractions over fundamental algorithms). Then you will be able to use software patterns with confidence, when it makes sense to do so.

Your economics professor is absolutely correct.

Software Design Patterns are primarily a way for experienced software developers to communicate with each other. They are a shorthand for established solutions to known problems.

But they should only be used by people who understand how to solve the problem without the pattern, or have come up with a similar pattern on their own. Otherwise, they will have the same problem as the copy/paste coder; they will have code, but they won't understand how it works, and therefore will be unable to troubleshoot it.

Also, many of the design patterns are enterprise patterns, patterns that are intended to be used in large, corporate software systems. If you learn the wonders of the Inversion of Control container, you will want to use it in every program you write, even though most programs don't actually need it (there are better ways to inject your dependencies in smaller programs that don't need an IoC container).

Learn the patterns. Understand the patterns, and their appropriate use. Know how to solve the same problem without the pattern (all software patterns are abstractions over fundamental algorithms). Then you will be able to use software patterns with confidence, when it makes sense to do so.

Your economics professor is absolutely correct.

Software Design Patterns are primarily a way for experienced software developers to communicate with each other. They are a shorthand for established solutions to known problems.

But they should only be used by people who understand how to solve the problem without the pattern, or have come up with a similar pattern on their own. Otherwise, they will have the same problem as the copy/paste coder; they will have code, but they won't understand how it works, and therefore will be unable to troubleshoot it.

Also, many of the design patterns are enterprise patterns, patterns that are intended to be used in large, corporate software systems. If you learn the wonders of the Inversion of Control container, you will want to use it in every program you write, even though most programs don't actually need it (there are better ways to inject your dependencies in smaller programs, way that don't require an IoC container).

Learn the patterns. Understand the patterns, and their appropriate use. Know how to solve the same problem without the pattern (all software patterns are abstractions over fundamental algorithms). Then you will be able to use software patterns with confidence, when it makes sense to do so.

1
source | link

Your economics professor is absolutely correct.

Software Design Patterns are primarily a way for experienced software developers to communicate with each other. They are a shorthand for established solutions to known problems.

But they should only be used by people who understand how to solve the problem without the pattern, or have come up with a similar pattern on their own. Otherwise, they will have the same problem as the copy/paste coder; they will have code, but they won't understand how it works, and therefore will be unable to troubleshoot it.

Also, many of the design patterns are enterprise patterns, patterns that are intended to be used in large, corporate software systems. If you learn the wonders of the Inversion of Control container, you will want to use it in every program you write, even though most programs don't actually need it (there are better ways to inject your dependencies in smaller programs that don't need an IoC container).

Learn the patterns. Understand the patterns, and their appropriate use. Know how to solve the same problem without the pattern (all software patterns are abstractions over fundamental algorithms). Then you will be able to use software patterns with confidence, when it makes sense to do so.