Tony Marston is a troll.
He doesn’t understand the difference between a pattern and a methodology. If anyone writes him and says they find patterns useful, he will immediately assume you use patterns as a methodology (like him).
I mean why else would you write an article called “design patterns are dead”.
First a little cliff notes. Tony Marston wrote a full-stack framework for building CRUD applications. The code is mediocre. He did an excellent job cataloging his components into a sort of pattern language others may learn from. He called these “transaction patterns” which I will refer to as “CRUD patterns”.
Each one describes a particular user story in the application, such as listing records. The same things have occurred in my applications, for instance having to let the user re-assign child records when deleting a parent record. So these are indeed patterns.
Then what is my beef?
He repeatedly contradicts himself while spewing biased mis-information. Let me show you exactly what he is doing.
Tony Writes
Because a "transaction" contains elements from a collection of different low-level design patterns it can be said to exist at a higher level. A "transaction pattern" is therefore a method of providing a description of this collection of design patterns which are used to satisfy the requirements of a user transaction.
http://www.tonymarston.net/php-mysql/design-patterns-are-dead.html
[A1] Tony Marston admits CRUD patterns are a way of cataloging a system just at a higher level of abstraction then design patterns. His framework uses them (design patterns and transaction patterns both).
Now here’s what he starts to get on my nerves
Tony Writes:
What you cannot do with Design Patterns
They are supposed to have more than one implementation, with different implementations of the same pattern having something in common with all the others. But if each implementation of a design pattern is supposed to be unique, where exactly is the pattern? If nothing is being shared between one implementation and another, then how can there be a recurring pattern?
Woah woah woah, come on Tony. You know what a pattern is. You wrote another article about just that:
In just another article Tony wrote:
A pattern provides a solution schema rather than a fully-specified artifact or blueprint. You should be able to reuse the solution in many different implementations, but in a way that its essence is still retained. A pattern is a mental building block.
* A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it.
* Patterns document existing, well-proven design experience.
* Patterns identify and specify abstractions that are above the level of single classes and instances, or of components.
* Patterns provide a common vocabulary and understanding for design principles.
* Patterns are a means of documenting software architectures.
* Patterns support the construction of software with defined properties.
* Patterns help you build complex and heterogeneous software architectures.
* Patterns help you manage software complexity.
Tony continues..
This provides us with the following definition
A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate.
http://www.tonymarston.net/php-mysql/design-patterns.html
[A2] In this statement Tony is doing a good job of showing how design patterns are useful because new programmers can learn about why experienced programmers are doing what they do. It provides advanced programmers a means to communicate with each other.
New requirement Tony is inventing that all patterns must meet?
Design patterns meet every one of those requirements he listed, but now all of the sudden he says a “pattern” must meet some new definition of the word “pattern” he just invented….
Tony wrote:What you cannot do with Design Patterns
Patterns or templates are supposed to have the following characteristics
- They are supposed to have more than one implementation, with different implementations of the same pattern having something in common with all the others. But if each implementation of a design pattern is supposed to be unique, where exactly is the pattern? If nothing is being shared between one implementation and another, then how can there be a recurring pattern?
- Parts of the original implementation are supposed to be abstracted out into a pattern which can be reused, thus making all subsequent implementations easier than the first. With software programs the reusable element is program code, but if there is no code which can be shared, if each implementation is unique, then where exactly is the pattern? Where is this reusability? If there is just as much effort required to create all subsequent implementations of a design pattern as there was with the first, then nothing is being reused, nothing is being shared. If that is the case then does a pattern actually exist?
http://www.tonymarston.net/php-mysql/design-patterns-are-dead.html
Then in email Tony Writes:
Something cannot be called a "pattern" or "template" unless it has a element
of re-usability. This requires that subsequent implementations take less
time than the initial implementation. If each implementation of a "design
pattern" takes just as long as the first because there is absolutely nothing
that can be re-used then the use of the term "pattern" is inappropriate.
Why all of the sudden are you adding this new requirement Tony? I wrote him and he provided no rationale justification. I asked him if his CRUD patterns used any design patterns (see A1 – Tony Marston uses design patterns). He said no. I told him about some of my architecture that is similar to his “list 1″ component. I mentioned I dont need List 1 – 10 or whatever because I have hook methods and a plugin architecture using observers (these are both 2 design patterns). He immediately switched into “my code is better than yours” defensive mode and stated about all the hooks he was using in his application. Haha tricked him. So tony here’s my new requirement for your vocabulary:
All hook methods must use bait method to catch a fish variable with the rod and reel component
Pretty silly if we just started adding new requirements for your method to be called a “hook”.
What am I saying here?
They’re just freaking words. Useful terms that establish a vocabulary programmers can use to communicate (see A2 – Tony originally defines a design pattern as a useful vocabulary). But then he feels the right to go off and write an article entitled “Design patterns are dead” and makes wild assertions:
- Design Patterns are the wrong level of abstraction
- What you cannot do with Design Patterns
How can he make such assertions?
Tony Wrote
I have said that I don't use design patterns, and I have given my reasons why. I have also written about CRUD patterns and why, in my opinion, that I think they are better.
I think he’s the only one using “that” logic.
In email Tony wrote
I already used my data dictionary to generate the table
classes from the database schema, so it was then a simple task to include
the facility to generate transactions from predefined transaction patterns.
If you cannot do the same thing with design patterns then this proves that
transaction patterns provide a higher level of reusability and therefore
productivity, which in turn means that transaction patterns are superior to
design patterns. Using that logic, why on earth should I want to use
something which is obviously inferior?
Reading what he wrote is like reading a carpenter’s writing who writes about why a drill is “better” than a saw. They are just different tools. They are not mutually exclusive tools, and in fact they don’t even solve any of the same problems. They don’t even really share a common applicability. So how can one be “better”? They don’t compete. Transaction patterns use design patterns (A1)
Not mutually exclusive!
Since they both solve different problems, I argue that each one is better at something different, at the cost of sucking at everything else. Design patterns excel at being a common vocabulary between programmers. I can talk to anyone else writing Enterprise applications (such as a version control system), and both terms are useful to us. With Tony’s CRUD patterns, I can talk about things at an even higher level, I can talk about specific screens within a CRUD application. But Tony’s CRUD patterns are of no use to me when writing a social network, for example.
So if Tony is going to say his patterns are better than design patterns he should at least state what and why. He does not though. He simply argues the definition of the word “pattern”. In talking with him he says we should not use names of design patterns to name components in our code, because design patterns obviously have no use. Why then would Tony use a “hook” in his code? Is he a programmer or a fisherman?
He is just a troll.
No New Programmers Allowed, E-Douches only
Tony Writes in e-mail:
I consider design patterns to be as much use as a "painting by numbers" kit
for novice artists. How many professional artists do you know who still use
such kits? None! Why? Because once they become proficient they don't need
them, just as proficient cyclists don't need training wheels.
As you can see he flip flops opinions, makes wild assertions, and when asked if he thinks design patterns could help new programmers program better he wrote the previous and following statements, which clearly indicates that he does not want anyone else to learn. My opinion is that he has a superiority complex or does not care that he is spreading mis-information so that he can make sales of his “radicore framework”.
I wrote and Tony replied
> Let's say you went golfing with Tiger Woods (I'm assuming you don't
> golf, if not substitute with some obscure sport like curling). If Tiger
> told you to just step up to the tee and swing, you probably would not
> be able to hit the bar as far him. Golfers have broken down their
> knowledge into patterns, like stance patterns, backswing patterns,
> follow thru patterns, that takes years of education and practice to
> master at his level of expertise.
The trouble is that different practitioners of an art (and programming is an
art, not a science) have different explanations as to what makes them good
at what they do, but what works for one person may not work for another. If
a person does not have the basic talent for an art form to begin with then
it does not matter what technique you try and teach him - he will always be
a failure.
Tony Writes
I certainly would not look at a piece of code and say "This looks pretty. I shall give it a name".
You have already sleighed new programmers entering the field. I am not surprised you would not be interested in analyzing the things you do or why you do them. You have already “mastered” them in your mind.
Tony Marston. Troll.
Ps > this post has been made in satire of his “crazy headlines” writing style. Maybe he should write a pattern on language on this next.
… well I hope not