Design patterns and reusable code

[pgb101]

Well, sure. However, I think if there were no Gang of Four, Fowler, etc. books, there would be even more names and it would be even more confusing. That is why I like PoEAA so much: it’s a baseline of communication and allows me to have discussions with other people that are grounded in a standard.

You have to remember for some there is no grey, it has to be 100% right or it is 100% wrong.

Impossible for some things so they must inherently be all wrong. Binary nature for the binary prose they write. Arguing the grey can never resolve anything as you will always be assumed that you are arguing the black, which just leads to pure frustration and combatativeness.

[Tony_Marston]

@auricle

Then you shouldn’t be surprised when they say “What you’re describing sounds like the … Pattern!”

So they’ve read Fowler and you haven’t. What’s the problem?

The problem is that too many people complain that I don’t user THEIR favourite patterns in exactly the same way that they do. I don’t talk about patterns in the same way as they do, and I don’t plan my use of patterns in advance as they do.

It is the same with my approach to OOP - “You are different, and difference is heresy!”

[Tony_Marston]

@Dan_Grossman

“Any back office administrative application” and “any application” are not the same thing. Rails/Zend/etc are “any application” frameworks.

You try and build an entire back office ERP application in one of those frameworks and see how far it gets you. Does it have built-in RBAC, Audit Logging? Workflow? Data Dictionary? Transaction generation?

You fail to realise that the needs of a “front office” website and “back office” application are entirely different, and the Radicore framework can out-perform ANY other framework when it comes to back office applications.

[McGruff]

One of the simplest and most ubiquitous design patterns is the lever. Levers are found everywhere. It would be rather silly to take up a position for or against them, or indeed any other design patterns. They just are. You can’t avoid them. Patterns will appear in code whether you are aware of them or not. That’s why they’re called design patterns, common solutions which keep popping up time and time again. Like the lever.

It’s important to learn about patterns because this is a good way to start thinking about how objects work together. Pattern lingo is common in the programming world. You have to know what people are talking about when they mention Decorators, Observer, and so on. How could you not want to learn about common solutions to common problems? Could you call yourself an engineer if you didn’t know what a rack and pinion gear is?

Most patterns are well-known and well-defined. MVC causes a lot of confusion (I’d be tempted to put it on the forum banned words list) but I don’t really think of it as a design pattern. Patterns describe the interactions between specific components (objects). MVC is more architectural, a broad-brush description of a way to organise an application into general logical themes (layers). M, V, and C will each break down into a series of tightly-focussed, co-operating objects.

If someone writes bad code which misuses design patterns, it’s just bad code. It doesn’t mean patterns are bad. I’m rubbish at chess. Does that mean chess is rubbish? What an awful, unthinking attitude to have.

Not knowing something isn’t a crime. The level of knowledge isn’t important: what matters is a willingness to learn. I don’t see that in the original poster. Just a lot of baseless assertions, straw men, and strident repetition of “I’m right and you’re all wrong”. Tony Marston: you are one of the worst bullshitters I’ve ever met, anywhere. I sincerely hope you find another forum where your talents are appreciated.

[Tony_Marston]

@McGruff

Patterns will appear in code whether you are aware of them or not.

But there is a big difference between deliberately trying to implement a pattern and writing code which you discover afterwards looks like so-and-so pattern. A “pattern implementor” is not necessarily the same as a “solution implementor”.

@McGruff

You have to know what people are talking about when they mention Decorators, Observer, and so on.

Knowing the names of patterns is not good enough. Each pattern can have a myriad of different implementations, so what if a particular implementation is faulty? What if the wrong pattern was chosen in the first place?

@McGruff

How could you not want to learn about common solutions to common problems? Could you call yourself an engineer if you didn’t know what a rack and pinion gear is?

Bad analogy. A motor engineer is brought up with such terminology as they are components in a final product, whereas for a software engineer the components are language instructions such as FOR and WHILE.

@McGruff

Most patterns are well-known and well-defined.

I disagree. Someone else has already said in this thread that design patterns are abstract concepts without any concrete implementations, and code reusability is not one of their aims. It is my opinion that there is very little of a reusable nature in design patterns at all, so I see no point in using them.

@McGruff

MVC causes a lot of confusion (I’d be tempted to put it on the forum banned words list) but I don’t really think of it as a design pattern.

So MVC is not a design pattern? Wash your mouth out!

@McGruff

If someone writes bad code which misuses design patterns, it’s just bad code.

I couldn’t agree more. The biggest technical disaster of a project that I have ever worked on was where the system architects planned in advance which design patterns were to be used, and with a separate component for each pattern they ended up with a system which had 10 levels of component between the user and the database. It was a nightmare to build and test as the linkage between one level and the next was too fragile and kept breaking. It took them TWO MAN WEEKS to implement a simple transaction, something which I can now do in FIVE MINUTES with my own framework.

This just proves (to me at least) that using design patterns does not guarantee success just as not using design patterns does not guarantee failure.

@McGruff

It doesn’t mean patterns are bad. I’m rubbish at chess. Does that mean chess is rubbish? What an awful, unthinking attitude to have.

I don’t write java, but I’m not saying that nobody else should write java. So stop putting stupid words into my mouth. My argument is that I do not see any tangible benefits from using design pattens, and I do not see any tangible deficiencies in NOT using them. YMMV

@McGruff

Not knowing something isn’t a crime.

So I’m not a criminal then. That’s good to know. I needn’t expect a visit from the paradigm police, then?

@McGruff

The level of knowledge isn’t important: what matters is a willingness to learn.

I am only willing to learn something new if it provides tangible benefits. I see no such benefits from design patterns, so I do not use them.

@McGruff

I don’t see that in the original poster. Just a lot of baseless assertions, straw men, and strident repetition of “I’m right and you’re all wrong”.

They are not baseless assertions, they have been drawn from personal and direct experiences. I have never said that design patterns should NEVER be used - they may be OK for newbies, just like training wheels on a bicycle or painting by numbers kits, but experienced developers shouldn’t need them any more.

@McGruff

Tony Marston: you are one of the worst bullshitters I’ve ever met, anywhere. I sincerely hope you find another forum where your talents are appreciated.

So I take it your’e not a fan then?

[McGruff]

@Tony_Marston

But there is a big difference between deliberately trying to implement a pattern and writing code which you discover afterwards looks like so-and-so pattern.

This is something you appear to be to be hung up on for some reason which I doubt would be interesting to pursue.

There’s nothing wrong with using a standard pattern if it’s a good fit for the problem at hand. Being consciously aware that you are using a design pattern simply means that you have read some books. Implementing a design pattern without being aware of it means that you are less well-read.

Not being well-read isn’t necessarily a problem. We all start out knowing nothing and then, hopefully, try to learn as much as we can from the best sources that we can find as well as our own experiments. However, sneering at other people who have taken the trouble to learn about things which you patently do not understand is just time-wasting bullsh*t.

@Tony_Marston

Each pattern can have a myriad of different implementations, so what if a particular implementation is faulty? What if the wrong pattern was chosen in the first place?

As I said in my last post but you failed to comprehend, just because I might be bad at chess does not mean that chess is rubbish. Even if I don’t understand it very well, I can still see that it’s a very subtle and sophisticated game. Your problem is that everything which you fail to understand is deemed to be rubbish. You do not have a sophisticated understanding of object-oriented programming and so you fail to realise the significance of patterns. More bullsh*t.

@Tony_Marston

I disagree. Someone else has already said in this thread that design patterns are abstract concepts without any concrete implementations, and code reusability is not one of their aims. It is my opinion that there is very little of a reusable nature in design patterns at all, so I see no point in using them.

Let me get this straight. It has been explained to you that design patterns are not about about code re-use and yet you still choose to criticise them on these grounds. Bullsh*t.

@Tony_Marston

So MVC is not a design pattern? Wash your mouth out!

Call it an architectural pattern if you like.

Nice turn of phrase though, along with others where you sneer at an imaginary clique of pattern-police. More bullsh*t. Your personal hang-ups really aren’t very interesting to discuss. There isn’t any real information being processed - just tedious rebuttals of your bigotry. A programmer isn’t going to learn anything useful from this but, to be fair, it might be interesting to a psychologist.

@Tony_Marston

It took them TWO MAN WEEKS to implement a simple transaction, something which I can now do in FIVE MINUTES with my own framework.

That’s got a real, pungent whiff of something… Can’t quite put my finger on it…

@Tony_Marston

This just proves (to me at least) that using design patterns does not guarantee success just as not using design patterns does not guarantee failure.

Did anyone say it does? Quote a source or shut up.

@Tony_Marston

My argument is that I do not see any tangible benefits from using design pattens, and I do not see any tangible deficiencies in NOT using them. YMMV

I detect no argument just stubborn assertions and occasional sneers.

@Tony_Marston

I am only willing to learn something new if it provides tangible benefits.

No you’re not willing to learn. You could though, if you wanted to. There are some very knowledgeable programmers on this forum. However, you’d rather fire off salvoes of toxic opinion which alienate everyone who might otherwise have been delighted to help you. That’s kind of sad - as well as bullsh*t, of course.

@Tony_Marston

So I take it your’e not a fan then?

Not really but I console myself with the thought that, in times of economic recession such as these, it is surprisingly inexpensive to have someone killed.

[Dan_Grossman]

This thread has taken a turn for the worse so I’m closing it. If anyone wants to continue discussing design patterns, feel free to start a new thread, but leave the personal attacks and self-promotion out of it. Neither is acceptable behavior here.