Jump to content
  • Advertisement
Sign in to follow this  
Sambori

The State Pattern

This topic is 2994 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Quote:
Original post by ApochPiQ
Quote:
Original post by M2tM
Finally, one last point, I am not sure if this was directed at me or not:

Quote:
ApochPiQ: Also, on a related note, refactoring code to suit a pattern is just boneheaded religion.


When I said this:

Quote:
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 meant what I said. I didn't mean refactoring code to suit a pattern, but rather in refactoring structureless blob-like code you'd probably end up formalizing and adding patterns by accident even if you didn't know that's what they were. If my first comment in this thread went unnoticed and people are misreading me by thinking I'm advocating refactoring to suit patterns I strongly urge you to re-read my first post with <sarcasm> tags around it.



No, that wasn't directed at you at all. It was just a general remark. In fact I like your wording a lot - patterns are to be discovered, not driven towards.


Cool, the paranoia kicked in when I read it and realized I said "refactoring" and "patterns" in the same sentence (kinda via reference with "they"). :D

Share this post


Link to post
Share on other sites
Advertisement
Patterns form the base of proper O.O design, how objects are related and put together.

How to not violate the main principles of O.O design is by using patterns.

I would say Patterns are Effective O.O ;-)

Share this post


Link to post
Share on other sites
Quote:
Original post by Sambori
Patterns form the base of proper O.O design, how objects are related and put together.


You're stating an unproven assumption. That's certainly not the intention of patterns as discussed by the GoF book. Its possible to have a proper OO design that doesn't use patterns.

Quote:
Original post by Sambori
How to not violate the main principles of O.O design is by using patterns.


You don't have to use patterns to follow SRP principles. They're not necessary for abstraction or encapsulation either.

Other posters are correct that any project of sufficient size will have patterns emerge in its implementation, but no-one was ever arguing that using patterns at all was bad.


Quote:
Original post by Sambori
I would say Patterns are Effective O.O ;-)


Everyone is entitled to their opinion, but nothing of what you've stated here supports your assertion that patterns are the foundation of good design.

Share this post


Link to post
Share on other sites
Quote:
Patterns form the base of proper O.O design, how objects are related and put together.


1. Many people already have told this - patterns don't form anything, they are simply names for certain pieces of programs that we're using quite often.
2. Discussions have lots of arguments thrown around. You have given us no arguments of any kind that would support these weird claims. So it's hard to call this piece of text a discussion.

Share this post


Link to post
Share on other sites
I disagree. The intent of patterns as of GoF is somehow dated.

My original post was about how to best use the State Pattern in game AI. More specific, where to put the core AI, in state objects, or keep it in the game character object.

Each pattern satisfies all the OO principles.

Each OO principle can be applied using any pattern based on the problem.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sambori
I disagree. The intent of patterns as of GoF is somehow dated.


Any further thoughts on this beyond your own opinion? Given that the GoF is probably the best-known and most-used set of patterns to this day, I'd say that their input is still highly relevant.


Quote:
Original post by Sambori
My original post was about how to best use the State Pattern in game AI. More specific, where to put the core AI, in state objects, or keep it in the game character object.


Which shows the problem with your approach and the reason why patterns are descriptive, not prescriptive.

Quote:
Original post by Sambori
Each pattern satisfies all the OO principles.


A pattern satisfies OO principles, but not all objects satisfying OO principles are pattern objects. That's the whole point. Patterns are not the base of effective OO, effective OO is the base of patterns. Patterns are descriptive language for common OO techniques.

Quote:
Original post by Sambori
Each OO principle can be applied using any pattern based on the problem.


No, just no. A pattern is good for solving a specific problem. Each pattern uses one or more OO principle. A pattern is not applied to implement an OO principle. You're stating this exactly backwards.

Also, you haven't actually supported any of your assertions. Your arguments have been generic to the point of being meaningless.

Share this post


Link to post
Share on other sites
I think I have problem expressing my original post. Whatever we say about patterns is all generic and biased.

Anyone could support his/her argument so far? No.

Share this post


Link to post
Share on other sites
Unrelated, but kind of important:

It's worth pointing out in this discussion that many of the GoF patterns are actually pretty strongly tied to the languages they are represented in and are meant to address specific problems encountered in those languages.

Many of them do not have any real purpose in languages which have automatic garbage collection, prototypes (dynamic class modification), or a duck typing built in to the language. Some do, some are implemented differently, but it's an important consideration when making broad statements about GoF patterns being prevalent in -every- program...

In the C++ world, sure, most programs of sufficient size probably do. In other languages you encounter different patterns, or familiar patterns implemented much differently as in PHP or javascript/Actionscript or whatever. It's very narrow to suggest OOP must be based on a set of prescribed patterns. Patterns emerge in everything, but unless your job is to make lace you probably aren't looking to make them.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sambori
Anyone could support his/her argument so far? No.


Um, yes.

Most everyone here has posted detailed arguments for their points - except for you. Just look at the size of the average post here, compared to the size of your posts. People are putting a fair amount of effort into supporting their arguments. You aren't showing any.


As to your original post: the entire point people are trying to make to you is that your question is broken. You're thinking of the state pattern as something to aspire to, something you should target, something you should try to emulate; this is bad.

Tell us what AI problem you want to solve. Tell us how your game/application is supposed to work. Tell us what you are trying to achieve. Then we can help you come up with a good design.


Trying to use patterns to dictate your design will get you bad results. That is why everyone is belaboring this point so heavily here. We are dealing with your question - you're just not getting the answer you want to hear.

Share this post


Link to post
Share on other sites
Quote:
Anyone could support his/her argument so far? No.

Let's break it down to really simple things:
-patterns came after the code they were first written in -> patterns described already existing, recurring solutions
-OO languages came before patterns -> they weren't designed to fit patterns -> patterns aren't the "center of OO programming"
-not all OO languages can support all patterns -> they weren't designed to fit patterns -> patterns aren't the "center of OO programming"
-people have written OO code in non-OO languages ( http://www.planetpdf.com/codecuts/pdfs/ooc.pdf ) -> how does your idea about patterns being the center of OOP fit in that? :D

I think these are good enough arguments to the idea(--definition of patterns) that patterns don't describe what you have to do, patterns describe what has been already done so that people could just have a name for pieces of code they use often.

[Edited by - snake5 on October 8, 2010 8:13:09 AM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!