Quote:Original post by Sambori
I'm talking about "patterns" not "AI" idiot!
Uh, your strange quotations made me miss this part. Really, calm down now.
The State Pattern
Uh, your strange quotations made me miss this part. Really, calm down now.
Quote:Original post by Sambori
This is a professional forum and keep on mind that many people are highly professional and older than you. So show some respect.
Quote:Original post by Sambori
Avoid such an attitude at interviews. This will never get you a job in the software industry.
Talking down to us is not likely to win you any points in the discussion. Plenty of us are professionals, you know, and likely have more experience than you. None of that really amounts to anything on an online forum -- what matters is whether you can argue your case. From my point of view, you have failed to do so, and are now trying to appeal to your own authority.
Quote:Original post by Sambori
I'm talking about "patterns" not "AI" idiot!
Go back and re-read your original post. You absolutely are talking about AI. It would be wise to avoid calling people idiots.
The best design comes from figuring out what materials and techniques you need to build the bridge before determining how big it has to be or what kind of load it has to bear... Right?
I am aware of a growing community of developers who dislike patterns (or specifically, the design by patterns school of thought), but consider the following:
Most introductory books on OO languages and computer science curricula only go as far as to say "OO is about inheritance" or something else as naive and as shallow. Very few books and courses provide any real insight on how to build real software systems using OO techniques. Patterns, on the other hand, provide a systematic approach to teaching/learning these techniques that would otherwise have to be learned through years of trial and error and studying other people's code.
Furthermore, patterns are so broad and generic, everything you would write beyond "hello world" is covered by at least one. I would argue that if a programmer introduces unnecessary complexity by designing with patterns, its because they don't have a complete knowledge of the problem they are trying to solve, their programming language (and it libraries), or design patterns themselves. The work of bad software engineers who design by patterns is not a testament to the merit of designing by patterns.
If anything, patterns (both as a vocabulary and design philosophy) encourage structure, consistency, and robustness.
Most introductory books on OO languages and computer science curricula only go as far as to say "OO is about inheritance" or something else as naive and as shallow. Very few books and courses provide any real insight on how to build real software systems using OO techniques. Patterns, on the other hand, provide a systematic approach to teaching/learning these techniques that would otherwise have to be learned through years of trial and error and studying other people's code.
Furthermore, patterns are so broad and generic, everything you would write beyond "hello world" is covered by at least one. I would argue that if a programmer introduces unnecessary complexity by designing with patterns, its because they don't have a complete knowledge of the problem they are trying to solve, their programming language (and it libraries), or design patterns themselves. The work of bad software engineers who design by patterns is not a testament to the merit of designing by patterns.
If anything, patterns (both as a vocabulary and design philosophy) encourage structure, consistency, and robustness.
Quote:Original post by samgzman
I am aware of a growing community of developers who dislike patterns (or specifically, the design by patterns school of thought), but consider the following:
Most introductory books on OO languages and computer science curricula only go as far as to say "OO is about inheritance" or something else as naive and as shallow. Very few books and courses provide any real insight on how to build real software systems using OO techniques. Patterns, on the other hand, provide a systematic approach to teaching/learning these techniques that would otherwise have to be learned through years of trial and error and studying other people's code.
Furthermore, patterns are so broad and generic, everything you would write beyond "hello world" is covered by at least one. I would argue that if a programmer introduces unnecessary complexity by designing with patterns, its because they don't have a complete knowledge of the problem they are trying to solve, their programming language (and it libraries), or design patterns themselves. The work of bad software engineers who design by patterns is not a testament to the merit of designing by patterns.
If anything, patterns (both as a vocabulary and design philosophy) encourage structure, consistency, and robustness.
Well, actually first you present this: "I am aware of a growing community of developers who dislike patterns (or specifically, the design by patterns school of thought)" You're trying to push conjecture here because those are two completely separate facts. You are asserting A == B and it doesn't.
I agree with the second part of that.
Moving on, patterns are great conceptual tools for both referencing and for standardizing common implementation strategies. The major problem only really comes into play with new programmers without any real experience with them misappropriating the purpose and trying to retrofit design patterns into problems instead of solving problems with design patterns.
Not "everything beyond Hello World" is a pattern, most of them are architectural implementations of solved dependency and compositional problems. Many simple medium sized projects don't really make any special attempt at having a standard architecture and often omit the use of patterns pretty much entirely. Only through rigorous refactoring would they be discovered. I'm not saying this is a -good- thing, just that again, you're making baseless claims that have no ground in reality.
Much larger applications do for sure. Without them you'd end up with the blob anti-pattern (which is what several mid-size projects end up being.)
What software have you developed that you share this insight with us?
Quote:Original post by AntheusQuote:Patterns can greatly help setting up an object oriented game framework that can be used in different genres.And anal sex is great because it works on all genders.
That may be read as that you supporting his argument. ;D
First off, I was trying to be facetious in my initial statement. People who I've talked to (friend, colleagues, and people on other forums) who don't like the design by patterns approach often claim not to like patterns at all.
As far as my "everything beyond Hello World" uses patterns, consider that:
Every class wrapper ever written realizes the "Adaptor Pattern"
If your using C++ and not reinventing the wheel all the time, you've made extensive use of the "Iterator Pattern".
If your classes are compositions and make use of polymorphism (pretty standard stuff), you've no doubt made use of the State, Strategy, or Decorator Pattern (even if you didn't realize it).
If you use C# at all you've no doubt encountered Delegates and Events (which are a part of the language!) which when used as intended, realizes the "Mediator Pattern". Every GUI program you've ever written also likely realizes Mediator.
Any of us game programmers who have implement a scene graph (whatever a scene graph means to you) have realized the "Composite Pattern".
I could go on all day dude. My claims aren't "baseless" - Patterns are unavoidable. Understanding them formally provides insight and understanding into what we developers are doing every day.
As far as my "everything beyond Hello World" uses patterns, consider that:
I could go on all day dude. My claims aren't "baseless" - Patterns are unavoidable. Understanding them formally provides insight and understanding into what we developers are doing every day.
First off: this thread is being watched. Act accordingly.
Secondly: patterns are often misunderstood. If you are treating patterns as prescriptive, you are doing it wrong, full stop, end of discussion. I unfortunately have misplaced my copy of the GoF book, but I distinctly recall something to that effect in the intro text (which apparently most pattern aficionados have never actually read).
Patterns are not intended to tell you how to design software. Patterns are post facto descriptions. Patterns are for talking about how you did something, not how you will do something.
Also, on a related note, refactoring code to suit a pattern is just boneheaded religion.
Design the appropriate solution. Then you can talk about it in terms of the patterns it most closely resembles, because chances are you will incorporate multiple patterns and variations on standard patterns if you did your design job correctly.
But design the appropriate solution. Patterns are a hammer; your problems are almost always screws, not nails.
Secondly: patterns are often misunderstood. If you are treating patterns as prescriptive, you are doing it wrong, full stop, end of discussion. I unfortunately have misplaced my copy of the GoF book, but I distinctly recall something to that effect in the intro text (which apparently most pattern aficionados have never actually read).
Patterns are not intended to tell you how to design software. Patterns are post facto descriptions. Patterns are for talking about how you did something, not how you will do something.
Also, on a related note, refactoring code to suit a pattern is just boneheaded religion.
Design the appropriate solution. Then you can talk about it in terms of the patterns it most closely resembles, because chances are you will incorporate multiple patterns and variations on standard patterns if you did your design job correctly.
But design the appropriate solution. Patterns are a hammer; your problems are almost always screws, not nails.
Quote:Original post by ApochPiQ
First off: this thread is being watched. Act accordingly.
Secondly: patterns are often misunderstood. If you are treating patterns as prescriptive, you are doing it wrong, full stop, end of discussion. I unfortunately have misplaced my copy of the GoF book, but I distinctly recall something to that effect in the intro text (which apparently most pattern aficionados have never actually read).
Patterns are not intended to tell you how to design software. Patterns are post facto descriptions. Patterns are for talking about how you did something, not how you will do something.
Also, on a related note, refactoring code to suit a pattern is just boneheaded religion.
Design the appropriate solution. Then you can talk about it in terms of the patterns it most closely resembles, because chances are you will incorporate multiple patterns and variations on standard patterns if you did your design job correctly.
But design the appropriate solution. Patterns are a hammer; your problems are almost always screws, not nails.
Thank you.
Quote:Original post by ApochPiQ
Patterns are not intended to tell you how to design software. Patterns are post facto descriptions. Patterns are for talking about how you did something, not how you will do something.
I think this view of patterns is too limited. Design patterns are descriptions of general tested solutions to recurring design problems. So if you learn about patterns, you have a toolbox of techniques that you can apply to solve design problems. Whenever you encounter a problem, you can search through this toolbox to see if there's a pattern that addresses that problem.
A while ago I read parts of the book Pattern Hatching, and it used design patterns in exactly this way (and that book was written by one of the GOF authors).
Of course, each pattern is meant to be used in a particular situation, and you should not try to apply a pattern to a problem it was not meant to solve.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
