Programming insanity, or am I just missing the point.
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
ednrgc wrote:
Well, 3 weeks, 4 projects, 35 files later, the project is done.
You are kidding. That must be nightmare to debug.
ednrgc wrote:
Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
And everyone. Sounds like your architect should find another place. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
What design pattern(s) are you using and what programming language?
-
ednrgc wrote:
Well, 3 weeks, 4 projects, 35 files later, the project is done.
You are kidding. That must be nightmare to debug.
ednrgc wrote:
Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
And everyone. Sounds like your architect should find another place. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
He sounds like an idiot.
BW
Quick to judge, quick to anger, slow to understand.
Ignorance and prejudice and fear walk hand in hand.
-- Neil Peart -
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
I just looked up "Design Patterns" and the definition seems rather vague. Could you explain what it means in this situation?
CleaKO
"I think you'll be okay here, they have a thin candy shell. 'Surprised you didn't know that.'" - Tommy (Tommy Boy)
"Fill it up again! Fill it up again! Once it hits your lips, it's so good!" - Frank the Tank (Old School) -
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
ooo, someone wedded to a buzzword :). I agree, patterns are interesting and useful, but only if they HELP. 3-4 weeks later cannot be justified so some zealot has it perfect. I'll bet they throw it away. You *did* keep your original, yes?
Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. Overheard in a cubicle: "A project is just a bug under development." Seeking to rise above the intelligence of a one eared rabbit...
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
ednrgc wrote:
To integrate it into other apps, you have to add the 4 projects into each solution.
So, was this project indeded to be used in other project as well? Was the initial implementation easy to rause? How hard was to recognize ANY pattern in your design?
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
ednrgc wrote:
I think that there is a time and place for everything.
I quite agree - I prefer to look at how best to do things on a project by project basis. For example, for the most part we use an ORM tool for database access, except for user profile authentication and authorisation data. We decided that the ORM tool gave us benefits but it wasn't secure enough for signing-in users.
Upcoming events: * Glasgow: SQL Server 2005 - XML and XML Query Plans, Mock Objects, SQL Server Reporting Services... Never write for other people. Write for yourself, because you have a passion for it. -- Marc Clifton My website
-
What design pattern(s) are you using and what programming language?
-
I just looked up "Design Patterns" and the definition seems rather vague. Could you explain what it means in this situation?
CleaKO
"I think you'll be okay here, they have a thin candy shell. 'Surprised you didn't know that.'" - Tommy (Tommy Boy)
"Fill it up again! Fill it up again! Once it hits your lips, it's so good!" - Frank the Tank (Old School) -
ednrgc wrote:
To integrate it into other apps, you have to add the 4 projects into each solution.
So, was this project indeded to be used in other project as well? Was the initial implementation easy to rause? How hard was to recognize ANY pattern in your design?
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
When I hear the phrase "Software Architect", I reach for my revolver headphones. i was thinking about this last night, in fact... i have an app that's grown organically over the past 9 years - features are bolted-on as they are needed, things are wedged-in here and there, etc., it's a beast - but people like it. now, there are some changes i'd like to make to it, to make it more useful for end users. but i don't see any way to make those changes without a near-total rewrite, which is something i'm just not up for. so i sighed and thought to myself "if only i'd sat down, nine years ago, and designed this thing in a Software Architect-approved Manner, using UML and state diagrams and use-cases and layers of abstract classes and clever messaging paradigms! it'd be so easy to make it do these things that it was never designed to do in the first place!" wait... what? of course it wouldn't!! even the best design is only fit to handle the problem as stated at the time - you can abstract it and try to make things flexible and modular, etc. but that's still just extending the design to things you anticipate, and you can't anticipate everything. and nobody can design for the things that will be demanded a decade later. for example, this is an imaging application, and there's no way i could've foreseen, in 1998, how widespread, cheap and popular digital cameras would become in 2007, or how things like Flickr would change how the pictures from those cameras end up on the web. i could've written it using the cutting-edge design and programming tools of 1998 and what would i have... a mess of ATL objects using DCOM? whatever. it still wouldn't help me solve the problem of making an app that was designed to do one thing well do something very different. you design as much as you need to, to get the job done in the time you have. anything else is jerking off. /rant
image processing toolkits | batch image processing | blogging
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
I agree with you completely. However, through my own experience, I realized that getting the work done is probably less important to the management (and the architect, in your case). What they are concerned with most is making themselves look good, everything else is secondary.
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
The way I understand them, Design Patterns deal with some predefined approaches for a small number of classes to interact with each other in a standard way to make code clearer and easier to understand. I don't understand how that turns a single page into 4 projects with 35 files. Things like design patterns and architecture exist to bring uniformity and simplicity to an entire application. A huge clump of loosely coupled individual pages that each have their own approach to solving a problem is just as bad as a morass of over engineered general purpose code that only gets used for one purpose. No implementation is going to be perfect and it's going to be some kind mix between the 2 extremes, but you should be able to look at every part of the design and defend how it makes the system simpler, easier to understand or what the constraints are that force it to break those rules.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
This sound like the old Child with a hammer problem... When you give a child a hammer, everything starts to look like a nail. When inexperienced developers first learn about things like COM, STL or design patterns, everything starts to look like a COM object/interface, an STL collection or implemented using design patterns. And like children, they do not appreciate/understand the repercussions of hitting everything with that hammer.
ednrgc wrote:
The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten.
That right there tells me all that I ever need and want to know about that architect... Peace!
-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
You're not missing the point. Patterns are there to be used when they make sense. If your current problem is sufficiently complex that it can be abstracted out to constituent patterns then great. Slavishly following ideologies seems vaguely communist to me - perhaps he's your very own political commisar.
Deja View - the feeling that you've seen this post before.
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
ednrgc wrote:
and not via (his view) of design patterns
this is one of the key points. Design patterns are more than just widdling a square peg to fit into a round hole! It's not about forcing the round hole, it is about finding the right pattern for the activity. I have pressed my team to use design patterns where they fit and are easily recognizable, and to at least consider what patterns match each subject as they are designing things. I have also reminded them that some patterns have similar purposes, and caution should be considered to find the right fit. In the GoF book they compare design patterns with architecture, in fact code architecture is definitely a good concept; but it is also pointed out that physical architecture has inter-use concepts, but not the same exact use. You don't want a wooden door on a shower stall, and yet the function is the same as a bathroom door. Conversely you generally don't want a glass door on the bathroom door, but it is quite acceptable on a shower stall. The function is similar, but the purpose is not. Design should never be forced. In fact, in the GoF book as well as Agile programming, Code Complete, and others, there are comments about detecting poor design by detecting poor fit for use. A design should fit comfortably for the purpose it was intended. It sounds like your design fit, his did not. I've had the discussion with someone else before and it ends in a stale-mate, but I will say it again, a design is not a superior design unless it considers performance. Balanced designs consider maintenance, creation, and run-time. If a design considers only the first 2 without even the slightest regard to the 3rd, then it is a 2 legged stool, and they are very hard to sit on properly.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I posted this here because it's a general programming paradigm question, not specific programming problem. I've been programming for too many years. I've seen paradigms come and go. The one that seems to work best for me is "black box routines" that do one thing, one thing only, and have no residual effects. I also follow the thinking that there is a time and place for everything. A recent addition to the Time and Place thinking has been Design Patterns. Here is my reasoning: On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns. We were given a task to create a single web page that lists some details of an item. That's all it is going to do, list details, nothing more. I created a "mock up" of the page that was fully functional and debugged in less than 2 hours. It consisted of a search page, clicking on the search findings displays the details of the selected item. The architect loved the functionality and was stunned that it was operational in such minimal time. When I told him that it was created using a loosely coupled technology and not via (his view) of design patterns, he said it was junk and had to be rewritten. It was a fully functional mini-app that is a black box routine that could be plugged into other apps easily. But he insisted that it be rewritten. Well, 3 weeks, 4 projects, 35 files later, the project is done. It runs slower than the original. To integrate it into other apps, you have to add the 4 projects into each solution. Again, I state that I am not against design patterns, but I think that there is a time and place for everything.
ednrgc wrote:
On my current contract, we have an architect who has been completely sold on Design Patterns at every cost. He believes that everything should adhere to his idea of design patterns.
Reminds me of a joke: how many design patterns a Java programmer needs to write a "Hello world" app?