Event and Event Handlers: I rely heavily on this one, event handlers subscribes to an event or you queue them to a certain event, when that event is emitted, it relays the info to the handlers which do their own thing. This pattern is simple, flexible but can be problematic sometimes (i.e. annoying if there is no async support, tight coupling if you are not careful, etc).
Hookers: This is inspired by the event pattern above, I use this in my Template System. The way it works is I build a base template, then I define the segment (hooks) I want to extend if I am to reuse the base template. Just like event handlers, you also subscribe to hooks but in this case, it is done directly in templates reusing the base.
I took this one step further, you can have hooks within hooks, remove a particular hook with their respective handlers, hook before a hook and hook after a hook. Very flexible and speeds up building page templates.
State Pattern: I use this one for breaking down complex problems, it works but you can easily shoot yourself in the foot.
Pattern makes sense if you understand the "Problem Space", if you do understand the problem you are solving, the pattern to use would come naturally (sometimes you do need to freestyle around to see which would one would make sense)
Sometimes the result is a pure match to the pattern. Other times, I just adapt to something close to a pattern because I'm modeling a real thing and reality often doesn't fit the mold of a pattern in a book. I believe the GOF book acknowledges this so that people will know to be flexible and use Patterns as a tool, rather than an exact prescription.