Programming insanity, or am I just missing the point.
-
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?
-
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 Peartbrianwelsch wrote:
He sounds like an idiot.
He is an idiot. :-)
-
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:
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.
Another glaring example of the inablity of many in project leadership roles to seperate their perception from their ego. It is sad how often a good project spirals south because a manager dismisses anything that contradicts what he/she "feels" should be the "right way".
"We are all repositories for genetically-encoded information that we're all spreading back and forth amongst each other, all the time. We're just lousy with information." - Neal Stephenson
-
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
To be perfectly honest, you would probably make a very good software architect (the sane and smart type, not the stupid type). Software architects can do a lot of good as long as they are realists, pragmatic and keep the clear vision that the job they hold is to make the job of the other programmers as EASY as possible so they in turn can deliver a top notch product quickly to the end users.
Tim Smith I'm going to patent thought. I have yet to see any prior art.
-
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?
-
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 should have suggested a book Refactoring To Patterns[^] to you :) Caution: Java inside
Regards, Zdenek
Nothing is as persistent as a temporary solution (a lesson learned from my experience)
-
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.
In my opinion: no, you have not missed the point. However, even when I create a mock-up I give it some kind of thought and design it in a way that it is possible to expand it later and/or reuse the code. Regarding software architechts I have experienced both good and bad. Of course there's a need for a software architect, but he/she had better be a good one. ;) Sometimes when a professional craftsman reasons like the one you're describing, I wonder if they are insecure and want technologies and/or buzzwords that are known to be a good thing by the management. In that way if something goes wrong anyone would be "safe" to blame those technologies/buzzwords. I also think James has a point in his "child with a hammer" analogy. It's a common phenomenon when someone has been attending a course or education where they suddenly had an epiphany; they come back with the child-with-a-hammer syndrome.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
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'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.
Functions without side-effects. Alas, many programmers seem unaware of this concept and the advantages thereof.
ednrgc wrote:
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.
The way I look at Design Patterns with regards to "black box" programming is that it describes various ways for the black boxes to interact in a seamless fashion through the use of polymorphism. It's what object oriented programming should be about: Dependency Management. However, they should be used sparingly. They appeal to kid in us that loved sitting down with a box of Legos[^] and building all kinds of monstrosities.
ednrgc wrote:
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.
My advice would be to beat him at his own game. Get a copy of Design Patterns[^], if you don't already own one. Become familiar with all of the pat
-
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
-
ednrgc wrote:
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.
Functions without side-effects. Alas, many programmers seem unaware of this concept and the advantages thereof.
ednrgc wrote:
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.
The way I look at Design Patterns with regards to "black box" programming is that it describes various ways for the black boxes to interact in a seamless fashion through the use of polymorphism. It's what object oriented programming should be about: Dependency Management. However, they should be used sparingly. They appeal to kid in us that loved sitting down with a box of Legos[^] and building all kinds of monstrosities.
ednrgc wrote:
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.
My advice would be to beat him at his own game. Get a copy of Design Patterns[^], if you don't already own one. Become familiar with all of the pat
Leslie Sanford wrote:
Functions without side-effects. Alas, many programmers seem unaware of this concept and the advantages thereof.
'5' for that alone. :cool:
Leslie Sanford wrote:
next time say something like, "See? This is an interesting application of the Strategy pattern. It can be plugged into other apps easily. If we need a different approach, we can always write a different Strategy."
At which point they get into a long argument about what "design patterns" means to me... ;P
----
i hope you are feeling sleepy for people not calling you by the same.
--BarnaKol on abusive words
-
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 think reuse is WAYYYYYY less important than the code working. And working as simply as possible. I don't think the GOF should be shot. But the dorks who insist on classes with "factory" and "builder" -in- the class name... Well, they should be shot. Let's keep it simple...