SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 67
  1. #1
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Design patterns and reusable code

    If design patterns do not provide any reusable code then what is the benefit in using them?

    I have recently been engaged in an argument via email with someone who criticises my low opinion of design patterns (refer to Design Patterns - a personal perspective). He says that design patterns are merely a convention and not a reusable component. My argument is that something called a pattern is supposed to have a recurring theme, some element of reusability, so that all subsequent implementations of a pattern should require less effort than the first implementation. If design patterns do not provide any reusable code then what is the point of using them?

    I do not use design patterns as I consider them to be the wrong level of abstraction. I am in the business of designing and developing entire applications which comprise of numerous application transactions, so I much prefer to use transaction patterns as these provide large amounts of reusable code and are therefore a significant aid to programmer productivity.

    What is your opinion? Are design patterns supposed to provide reusable code or not? If not, and each implementation of a pattern takes just as much time as the first, then where are the productivity gains from using design patterns?

  2. #2
    Follow Me On Twitter: @djg gold trophysilver trophybronze trophy Dan Grossman's Avatar
    Join Date
    Aug 2000
    Location
    Philadephia, PA
    Posts
    20,580
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Patterns are solutions to common design problems. You learn the patterns then recognize when your task can be solved by one, rather than having to come up with a (perhaps less well thought out) solution of your own. They save you time at the design stage not the implementation stage.

  3. #3
    SitePoint Enthusiast
    Join Date
    Sep 2009
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One reason for patterns is they are a common language for us to communicate with one another. Some patterns like the Template Method pattern and Compose/Composed Method occur quite naturally over time. If you include a library from elsewhere and it will become intrinsic in your project then wrapping it with an Adaptor pattern limiting the public interfaces can also be the safest bet. Less promiscuity less possible problems.

    The problem with working with other peoples code is the possible lack of uniformity, patterns aid in the establishment of more uniformity and ease of communication to others through code. No project should never be viewed as always a one man project as things grow unexpectedely.

    You say you don't use design patterns but have you read them all? I get the impression that you think they are big things when really most of the time they are just simple structuring things to sometimes aid in DRYness. The things written using that structuring can be very reusable, though reusability always relies on the developers instincts and ability. There is no magic cure for that.

    Now I admit patterns are given a lot of over precedence compared to their sibling anti patterns as they are 'cooler'. Knowing anti patterns, even if you do not prescribe to using patterns are generalistic enough to be worth while reading. eg. Expection anti pattern, Big Ball Of Mud etc... In fact when I first heard the term patterns the first thing I read were the anti patterns, but that is because I like to focus on the negative as I am argumentative.

    There is also the anti pattern of misusing patterns Patternitis.

  4. #4
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Agree with what Dan said, they do not imply any reusability, just a common solution to an existing problem. Just 5 mins ago came across a nice example http://www.sitepoint.com/forums/showthread.php?t=653767

  5. #5
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    One of the main issues isn't so much the fact they prevent redundancy (in the reinventing the wheel scenario), patterns are different to conventions in that rather than give off a commonly held justification for doing things in a certain way allow us to reinforce an individuals ability to recognise and make use of elements of a website, it's much more than just trying to save time, it's about using psychology to familiarise people with their environment so they can carry out their browsing without being intruded upon or feeling like you need a phD to navigate a website, it's basically a way to improve usability whilst keeping things logical and agile.

  6. #6
    Follow Me On Twitter: @djg gold trophysilver trophybronze trophy Dan Grossman's Avatar
    Join Date
    Aug 2000
    Location
    Philadephia, PA
    Posts
    20,580
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlexDawson View Post
    One of the main issues isn't so much the fact they prevent redundancy (in the reinventing the wheel scenario), patterns are different to conventions in that rather than give off a commonly held justification for doing things in a certain way allow us to reinforce an individuals ability to recognise and make use of elements of a website, it's much more than just trying to save time, it's about using psychology to familiarise people with their environment so they can carry out their browsing without being intruded upon or feeling like you need a phD to navigate a website, it's basically a way to improve usability whilst keeping things logical and agile.
    This is a discussion of software design patterns in the sense of the famous book by the Gang of Four.

    I can hardly follow what you just wrote there, but it's definitely not on topic

  7. #7
    SitePoint Enthusiast
    Join Date
    Sep 2009
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dan Grossman View Post
    This is a discussion of software design patterns in the sense of the famous book by the Gang of Four.

    I can hardly follow what you just wrote there, but it's definitely not on topic
    I think the time difference and New Years here in England may have something to do with it

  8. #8
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Nope, it's not a drunken mishap! I was browsing the "New posts" list and picked this one up for reading. I thought by design patterns we were talking in the broader design sense of re-usable conventions as applied in general web design, rather than being exclusively programmer-centric (though I do agree my post wasn't really that good). I think patterns are useful as while they don't give us code, they assign us a commonly accepted methodology to ensure the implementation ticks as many boxes as possible, granted there may be better solutions out there but the patterns at least give us a solid baseline to work from

  9. #9
    SitePoint Evangelist
    Join Date
    Aug 2005
    Location
    Winnipeg
    Posts
    498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If design patterns do not provide any reusable code then what is the benefit in using them?
    I'm confused. I have followed your articles and work probalby since you first published ideas. You seem to understand what patterns are and their purpose, yet ask this question...which is fine just confusing.

    Patterns are not *only* about code reuse they have many benefits. Whether you implement a pattern (or series of) in a reusable fashion is dependent on the implementation not strictly the pattern.

    for instance, you could implement a front controller and MVC components in a single file, under a single class, but the degree of cohesion would be really high and thus not very reusable, at least in the context of cross application reuse. You could probalby reuse a method or two inside the class itself.

    Its better to divide and conquer and split each layer into its own class and distinct layer for more effective separation of concerns. Each component of the MVC triad would best be factored into its own file and class as opposed to being in a single file and God class.

    Cheers,
    Alex
    The only constant in software is change itself

  10. #10
    SitePoint Enthusiast
    Join Date
    Dec 2009
    Posts
    48
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have never seen a pure implementation by even the most dedicated pattern champions. If it can solve a problem then I try to use it but I never let it get in the way of actually solving the problem.

  11. #11
    SitePoint Evangelist
    Join Date
    Aug 2005
    Location
    Winnipeg
    Posts
    498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have never seen a pure implementation by even the most dedicated pattern champions
    What do you mean pure implementation? While I am not a patterns champion or expert (by definition I consider it an impossible goal) my own framework and software extensively uses existing patterns, I would exclusively if possible, but there are times when you must introduce your own patterns, because of lack of insight into all known patterns or because even a combination of existing patterns do not meet the requirements.

    In this sense, all software is driven by patterns, whether we realize or not.

    Template method is one such pattern, for anyone even trivially experienced in object oriented programming. It is frequently used and not even realized patterns are being applied.

    try to use it but I never let it get in the way of actually solving the problem
    There are times when I feel patterns have been abused, Zend framework for instance, goes a little heavy on abstraction for my liking and it results in complicated implementations (ie: Controller architecture is way to complex; Occams Razor was blatantly ignored, IMO).

    However you can still follow DRY KISS principles and apply patterns every, even in a purely OO fashion.

    Just because I find this discussion fascinating, would you mind explaining your personal experience where patterns *got it in the way*. I am not doubting they have or have not, I am just curious to hear other opinions, so I may factor those experiences into my own daily experiences.

    Cheers,
    Alex
    The only constant in software is change itself

  12. #12
    SitePoint Enthusiast
    Join Date
    Dec 2009
    Posts
    48
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hey Alex. I work with people who say they will use a pattern but somewhere along the way they break away from it when the pattern either makes it too complicated to understand or they just get lazy. MVC is a good example. Sometimes it's easier to drop some business logic in the view like building a dropdown box for yes/no. To me that's all okay just not "pure". Sort of how we cheat in database normalization when it's faster and requires less queries. Speed vs. correctness.

    I've been on several projects the last couple years where a lot of time was spent talking about theory and how this pattern is better than that one and we go off trying a couple different ones. Eventually picking one we all quickly break the rules. When in essence just about any one would have sufficed and time was lost getting the project done and into the market which ultimately costs the company money. I come from the world where it's more important to get it done and out there than to theorize and double the coding time to adhere to a pattern. The argument there is it costs more on the tail end debugging or updating by people who don't know what the heck the code is doing. But, I've found even well written code is difficult to understand because we engineers like to work on code that is written the way we would do it. It's familiar. That's really rare in my experience.

    That's a generalization and my own personal biases so I guess my point is to focus on the customer, which we engineers rarely do, and solve their problem and not worry so much what pattern we're using when in the end the rules will be broken anyway. Hope that makes some sense.

    Oh, back to the OP. The benefits are it can help reduce excess code and mistakes. The downside is it can create excess code trying to adhere to an ideal. I reserve the right to be wrong on that.

  13. #13
    Follow Me On Twitter: @djg gold trophysilver trophybronze trophy Dan Grossman's Avatar
    Join Date
    Aug 2000
    Location
    Philadephia, PA
    Posts
    20,580
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Who ever said you have to write "pure" implementations of patterns?

    Their purpose is to provide solutions to common software problems (echo?), not to dictate design or code.

    A visual design equivalent might be the "horizontal top navigation pattern". A group of web designers are talking about a client. They need to design a website and one suggests using a "horizontal top navigation" while another suggests a "vertical left navigation". Everyone understands each other because they recognize the common patterns, and they can choose one and work it into their design.

    Nobody should be upset that their implementation of "horizontal top navigation" is "unpure" because they added a secondary side navigation for some other elements. That's not the purpose of the pattern, it was just to use common solutions to guide the plan rather than reinventing the wheel or having to fully describe a design nobody else is familiar with.

    If you're having the software equivalent of that purity argument, then the problem isn't the existence of the design patterns, but your expectations of their role. You're taking them too seriously. You can be pragmatic about how you use design patterns! Choose a pattern, break up the tasks according to that pattern, and let your team get coding. That the end result doesn't look like the pattern doesn't in any way change that it helped you get started, and at least start in a direction that isn't terribly designed.

  14. #14
    SitePoint Zealot
    Join Date
    Mar 2007
    Posts
    192
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @Dan Grossman

    I dont mean to be condescending to you.. but I think you misunderstand what a design pattern is in the first place.

    Comparing a "horizontal top navigation" to a design pattern (design patterns including things like MVC, OR/M, TS, CoR, Repository, IoC ... etc) IMHO is incorrect. In front end web design, the horizontal top navigation "pattern" or as i would call it "trend" is more comparable to a functional piece of a site such as "membership" or "form processing". Design patterns refer to best pratise methods in which to solve a problem. An easy example is the Repository pattern.

    The repository pattern, which is well demonstrated by linq to sql (asp.net). It provides a data abstraction layer which allows your business logic to agnostically retrieve data whether it is from a database (whether mysql or oracle) whether its from an xml file or YML file, or whether it is checking a cache for the data first. The repository will also typically hide the calling components from things like sql and xpath. It typically will serve the calling components some sort of application structure representation of the data (IE linq to sql provides an object based view of data, think OR/M).

    Keep in mind that linq to sql itself is not demonstration of the repository pattern, but the object query operators make it very easy to build one.

    Ruby on rails uses active record for its data representation which I think is quite similar to a repository.. in fact a repository could probably wrap an active record implementation.

    I agree with PHPKick in sometimes needing to break out of the recommendations of a design pattern, such as putting small bits of business logic in the view. Esp in web programming business constraints are a large part of our work, having to get things out the door quick. But sometimes hacks like that really are the bane of software projects costing maintenance and making changes harder and more complicated to do.

    Design patterns also help a lot with test driven development as they help you properly compartmentalize code into components that serve the next layer of calling components. So you can easily build tests to verify the functionality of nicely layered and component oriented code.

    Your job as a programmer is to determine how important it is that all this be implemented. Obviously if you are making a simple script to collect some user data and save it to the database and send an email to someone you arent going to go about erecting a layered application with a repository and services that send email, and caching, and queues and what not, because your only getting 200$ to implement this script on a small site that probably wont receive more than 100 hits. So screw it build a quick transaction script that validates, db inserts, and emails the data and displays a thank you message. Easy and done. Profit made.

    Now expand that into a larger site in which multiple features of a site do email sending and interact with a database. Well obviously there are alot of ways to go about this, you may have requirements to fetch data from some sort of REST service like iContact, or you might need to screen scrap some data from somewhere... so design patterns help you build such things so that email sending is built as component that can be used by other components (contact forms, or request a quote forms, or refer a friend type things).

    Then with data access requirements you can build a single component that handles these data access requirements and that prevents you from having to duplicate and debug this code everytime you need to use it.

    I guess in conclusion I think that design patterns are worth the time and money saved when you have requirements in which implementing a design pattern will save time and money. Yes, thats a bit of a weird sentence, and thats why you are the software engineer that needs to decide what is the best option in terms of completing requirements, adapting to changes, maintenance and business requirements, budget, etc.

  15. #15
    Follow Me On Twitter: @djg gold trophysilver trophybronze trophy Dan Grossman's Avatar
    Join Date
    Aug 2000
    Location
    Philadephia, PA
    Posts
    20,580
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by voodoomagic View Post
    I dont mean to be condescending to you.. but I think you misunderstand what a design pattern is in the first place.
    I do, I was just trying to build a simple enough situation where it'd be clear that getting upset about "breaking the pattern" is unwarranted. I was not trying to imply that "horizontal navigation bars" are a real pattern.

  16. #16
    SitePoint Zealot
    Join Date
    Mar 2007
    Posts
    192
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Right, but horizontal top navigation is not a pattern.. its a design trend.. I dont see how pretending it is a pattern gives a good example of why design patterns are not economical.

  17. #17
    Follow Me On Twitter: @djg gold trophysilver trophybronze trophy Dan Grossman's Avatar
    Join Date
    Aug 2000
    Location
    Philadephia, PA
    Posts
    20,580
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by voodoomagic View Post
    Right, but horizontal top navigation is not a pattern.. its a design trend.. I dont see how pretending it is a pattern gives a good example of why design patterns are not economical.
    Do we really need to have this discussion? Substitute your favorite real pattern into the conversation. This is called analogy. It was the conversation that was important (using a pattern to agree on what to do, then not being upset if the end result didn't perfectly match the pattern, because following the pattern isn't the real goal, it's communicating clearly and getting to work). Analogy shows a point by comparison to another situation, rather than talking about the situation in question (design patterns) directly.

  18. #18
    SitePoint Enthusiast
    Join Date
    Sep 2009
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree with PHPKick in sometimes needing to break out of the recommendations of a design pattern, such as putting small bits of business logic in the view. Esp in web programming business constraints are a large part of our work, having to get things out the door quick. But sometimes hacks like that really are the bane of software projects costing maintenance and making changes harder and more complicated to do.
    It can also mean having to go on a code hunt to find the implementation. Consistency is very important as it means you always know where to go, what a method starts with etc. Our own brain cycles cost and we can cost others theirs whether they be developer or end user.

    I guess in conclusion I think that design patterns are worth the time saved when you have complex requirements in which implementing a design pattern will save time and money. Yes, thats a bit of a weird sentence, and thats why you are the software engineer that needs to decide what is the best option in terms of completing requirements, adapting to changes, maintenance and business requirements, budget, etc.
    Also known as managing technical debt. What always amazes me with developers we can all use the same terms ( KISS, DRY, YAGGNI ) and have pretty different understandings. All you can do is go with the gut and try and ensure that your own personality faults ( laziness etc ) are not mis-appropriating your actions. The subconscious will lie and make your consciousness believe you are being altruistic, it is pretty sneaky that way.

    Rigidity and high level programming do not really go together as the solutions we mostly build are for direct human interaction. Possibly with people who mutter things like 'blue sky thinking' having a bit too much say in the outcome it is as much a fight with them as it is with the code.

    Being too puritanical is a major personality flaw in an application developer as the outcome is that usability/functionality can comes second to the code if allowed. If the developer can argue well they might say it is impossible and some non technical management will accept that as fact. That as far as I am concerned is a mortal sin, it muddies the water with managers after they have learnt they have been duped before when they are with another developer when it is now actually technically impossible.

    How does that tie into patterns? Patterns were not invented just to indulge our whims as developers, they were created to help us with problems we may face in an elegant manner in a way that is not crazy, and there is a lot of crazy out there. Too much coffee== possibly crazy code, too much partying==possibly crazy code, problems with the wife==possibly crazy code.

    As all possible problems can never be imagined all possible solutions cannot be prior created.

    The gang of four never stated "We are the pattern gods and ye are our legion of brainless donkey followers". No-one has ever said we cannot make our own patterns and that our individual creativity must be sacrificed, they just have to be very easily communicable outside our peer group. People move on, people come in.

    Anyway I agree this is a very interesting topic. The never ending quest in how to design good software. A lot of possible arguments in this one

  19. #19
    SitePoint Zealot
    Join Date
    Mar 2007
    Posts
    192
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I just realized that you were not the thread starter :P...

    So to avoid a fued, I agree with your initial response to this thread. However I still dont think that horizontal box nav is comparable to a design pattern.. but lets not waste our time arguing lol.

    Happy new year

  20. #20
    SitePoint Zealot
    Join Date
    Mar 2007
    Posts
    192
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston View Post
    If design patterns do not provide any reusable code then what is the benefit in using them?
    To finish off my opinion on this...: they don't. They provide reusable problem solving and are language agnostic. It is up to you to implement solutions to problems using design patterns to help solve those problems once. Hopefully your solutions will end up being reusable code.

  21. #21
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,786
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    As has been previously specified a design pattern is a known solution to a particular problem. By using it when you have that particular problem to solve you know that the solution will work. It may not be the best solution when you consider everything since other aspects of the overall problem may mean that a totally different solution that completely bypasses the problem that pattern solves may be better if you can actually juggle enough design concerns to rework things at that level.

    What it does do is to guarantee that if you can define the overall problem in terms of patterns that have been solved previously then you will have at least that one solution to the overall problem that is guaranteed to work correctly (provided that you implement it properly). With any other solution there is at least the potential for you to have overlooked something in the design that means that even though the design is implemented correctly it doesn't always produce the correct result due to a flaw in the design.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  22. #22
    SitePoint Wizard
    Join Date
    Apr 2002
    Posts
    2,301
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    > However I still dont think that horizontal box nav is comparable to a design pattern.. but lets not waste our time arguing lol.

    the whole concept of design patterns originally came from Christopher Alexander, an architect (houses, buildings type of architect). in that an organisation of a door and windows; or sofa, chairs, windows and tv; or houses, shops, paths, trees etc. (depending on what scale you're working) can be a design pattern. a pre tested, proved to work well practically and aesthetically organisation of elements in particular situations which can be taken off the shelf as it were and applied to your particular situation with varying degrees of flexibility. pre designed organisations. units of design, which themselves can then be put together, presumably according to further design patterns (nested patterns). so in that general non programming, non oop sense of design patterns, horizontal top navigation fits quite happily. i guess voodoomagic you're thinking of design patterns specifically within the bounds of oop maybe, which is an area who have taken design patterns so seriously to give the impression of complete ownership of the idea. but that's not the case. in fact Christopher Alexander's recent books i believe start to point out the nature of patterns he's been so tied up with so far as architecture goes, actually can be applied to life and matter etc.; he's proposing it as a way of interpreting everything... a new science! so clearly design patterns aren't tied to oop.

  23. #23
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    As has been previously specified a design pattern is a known solution to a particular problem.
    I believe that is technically incorrect. A design pattern is NOT a known solution but the DESCRIPTION of a solution. The actual solution, ie. the program code, you still have to build yourself. Therein lies a problem. Describe a solution to a bunch of programmers and they will each produce a different chunk of code with different levels of efficiency, reusability, maintainability, etc. Take one step back and describe the problem (not the solution) to a bunch of programmers and see how many different solutions they can propose. This means that a bunch of programmers could potentially propose a different combination of design patterns as the solution to the same problem.

    There is no guarantee that when a programmer says "I have used so-and-so pattern" that it was the right pattern to use in those circumstances, or even if the implementation fulfilled the objectives of that pattern. I have seen programmers look at the same piece of code and fail to agree which pattern it implements. I have also seen programmers argue that only THEIR implementation of a design pattern is the correct implementation. For example, in the MVC design pattern I have come across these different opinions:
    - the model must push its data to the view.
    - the view must pull its data from the model.
    - the controller must pull the data from the model and push it to the view.

    Who cares? The MVC pattern describes the role of each of the three components, and the mechanism by which the data moves between the components should be totally irrelevant. Yet it still causes arguments.

    It is also possible to use a pattern inappropriately. Some patterns were created to get around deficiences in the language. For example the strategy pattern was designed for languages without polymorphism, which implies that if you are using a language which DOES have polymorphism then the strategy pattern is a waste of time.

    Using design patterns does not guarantee any level of success. The only project I have ever worked on which was a total disaster was one in which the system architects decided up front which design patterns were to be used (they chose ten of their favourites) then insisted that each pattern be implemented in its own component. The result was over-engineered and over-complicated. It took two man-weeks to build what should have been a simple component, something which I can now achieve in five minutes, so it quicky went over budget and was cancelled by the customer.

    Some people say that the only advantage to design patterns is to provide a common language between programmers when they are talking about their code, so that they use abbreviations instead of long-winded descriptions. This is in fact simply domain-specific jargon, similar to what you can find in any profession. For example, in the motor trade you would not say "the apparatus for charging air with a fine spray of liquid fuel for combustion" but instead would use the abbreviation "carburettor". Later on someone says "My car doesn't have a carburettor, it has fuel injection" and that confuses everbody.

    So design patterns mean different things to different people. Some see them as reusable solutions whiles others see them as descriptions of solutions.
    As far as I am concerned design patterns fail because they offer little or nothing in the way of reusability, and as a common language they fail because the same terminology means different things to different people.

    Design patterns are simply a tool, one of many, and like any tool they can be used, mis-used, over used and even abused. Using them does not guarantee success, just as not using them does not guarantee failure.

  24. #24
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston View Post
    Design patterns are simply a tool, one of many, and like any tool they can be used, mis-used, over used and even abused. Using them does not guarantee success, just as not using them does not guarantee failure.
    And your point is?

  25. #25
    SitePoint Enthusiast
    Join Date
    Sep 2009
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I believe that is technically incorrect. A design pattern is NOT a known solution but the DESCRIPTION of a solution.
    I agree on that point..


    The actual solution, ie. the program code, you still have to build yourself. Therein lies a problem. Describe a solution to a bunch of programmers and they will each produce a different chunk of code with different levels of efficiency, reusability, maintainability, etc. Take one step back and describe the problem (not the solution) to a bunch of programmers and see how many different solutions they can propose. This means that a bunch of programmers could potentially propose a different combination of design patterns as the solution to the same problem.
    You are really arguing against here is the human element and that humans are fundementally different. All this really highlights is why some developers are potentially paid/worth more that others. If businesses could wave a magic and guarantee a large scale system would not turn into a boat anchor and pay someone $8 hour to do they would do it. I will say this industry is still is still in it's infacy and requirements will always outscale solutions due to the systems allow businesses to be competetive, unless we get to the point where computers can programme themselves there will always be this human problem.


    Who cares? The MVC pattern describes the role of each of the three components, and the mechanism by which the data moves between the components should be totally irrelevant. Yet it still causes arguments.
    A lot of developers are argumentative, a lot of us like having our brain consumed 100% possibly due to we get a pleasure reward from doing it. Stress, tension and anger can all feel good if that is your makeup and that drive also pushes things forward. Design patterns are good as they at least get people talking about design, there is an awful lot of mess in PHP land due to the lack of thought about design prior to 3 or so years ago. PHP 5 moved things along a lot in the group mind as suddenly there was OOP ( even though I will admit I have always done OOP even in 4 as I find procedural lacks from an organisational/ portability viewpoint at least ).

    You have to remember developers will argue :-
    1. Braces, where to put them.
    2. Tabs versus spaces
    3. Procedural versus OOP
    4. Whether a method should be split out into more private methods
    5. The name of methods/parameter count of methods/method count in a class/max size of a class
    6. Lambda versus Anonymous classes
    7. Javascript should not change to ECMCA SCRIPT 4
    etc etc etc
    Some of those things are worth while, one thing for sure you are always guaranteed developers arguing about something. I know I do it, a lot . And then who I am doing it with we switch sides the next time we go to the pub and effectiveley argue against ourselves, and even when we agree we argue about agreeing. Some people would call that being passionate, some would say an *** after too much guinness. Though we did argue to the same level who was the chief bar maid so the latter may be more appropriate. Though I will only argue if I deem it worthwhile..... Like barmaids who don't know OOP.


    Using design patterns does not guarantee any level of success. The only project I have ever worked on which was a total disaster was one in which the system architects decided up front which design patterns were to be used (they chose ten of their favourites) then insisted that each pattern be implemented in its own component. The result was over-engineered and over-complicated. It took two man-weeks to build what should have been a simple component, something which I can now achieve in five minutes, so it quicky went over budget and was cancelled by the customer.
    Well I am not a fan of big design up front as that in itself allows these problems, too much mental low level implementation that early on is fun for the person doing( doing new stuff is always fun as it is like a developer party where they can get wild with the cool new stuff ). Again this is a people problem, doing in this case is more fun than actually finishing for them. I have seen that gleam a few times and it is a destructive mentality, I can't stand it I see it as a personality flaw. Building stuff that no-one uses due to personal ineptness is failure however much fun the journey to failure is.



    Some people say that the only advantage to design patterns is to provide a common language between programmers when they are talking about their code, so that they use abbreviations instead of long-winded descriptions. This is in fact simply domain-specific jargon, similar to what you can find in any profession. For example, in the motor trade you would not say "the apparatus for charging air with a fine spray of liquid fuel for combustion" but instead would use the abbreviation "carburettor". Later on someone says "My car doesn't have a carburettor, it has fuel injection" and that confuses everbody.
    That analogy is a bit off, English is flawed people are flawed and get things wrong. Looking like an idiot is something everyone does and can be the source of funny. Verbalisation can be a very hard thing with developers.
    I see the term MVC in a job spec I think
    1. They use a front controller, seperate php pages cause more organisational overhead as they tend to be harder to keep DRY. I hate repetetives as it shows lack of discipline and for me to maintain it then I would have to move it to a front controller, plus 1 page out of 40 could be radically different in process and that would be documented in the controller by having a different flow, this makes changes easier to make as they can be trusted more without opening 40 files.
    2. They are organised in their approach and don't believe in the living in the moment thing in php of echoing "<table>" doing an SQL statement, going into 5 levels of nested ifs and whiles with some more copied and pasted SQL statements doing insterts/updates etc. There is enforced structuring that developers are constrained to some degree, though developers will always be able to make a fug ball in a most creative fashion out of anything given to them when they get bored.

    There is no point me going to jobs that do not have some respect for those things, I don't want to have 9 years experience doing the same year. Waste of life. Plenty of other people out there who just want a pay check and goof off on messanger a lot when they should be bettering their skills. I admit I do seem to denigrate developers but we are a varied species. That is not to say I would not go for jobs mentioning not mentioning MVC but it helps me see their worth, but I definately would not go for jobs mentioning some popular things that break those rules in glorious fashion.

    Now if they wanted someone to sort it out and I had the trust then I would, I love refactoring. Turning a pigs ear into a silk purse is also a challenge I think less people can do than building something from new. The right bits have to be targetted in the right order and takes a lot of patience and meticulousness.

    So design patterns mean different things to different people. Some see them as reusable solutions whiles others see them as descriptions of solutions.
    As far as I am concerned design patterns fail because they offer little or nothing in the way of reusability, and as a common language they fail because the same terminology means different things to different people.
    They can help in writing reusable software. I think your only real possible problem is you forget what it was like when you first entered into the field and how much crud there is out there now. Design patterns are a mental building blocks of approaches that give people a structuring to work off, thinking in ideas instead a big sequential train of downward action. Now I will admit that is just an OOP thing but a lot of people don't get OOP and done wrong it is very painful.

    What they can offer..
    1. Composed method, very good readability. When readability diminishes then it is a sign that there are too many responsibilities as sequential method call flow becomes very hard and method count is forcefully increaed indicating a need for refactoring.
    2. Template method pattern, the abstract class has a large degree of design importance( ideally all the important ). The child classes are fundementally there to finish the configuration/ do domain specific actions whose trigger action is called by the parent. This one can be very reusable as those child classes can finish of configuration for different projects/technologies, such as help with the initialisation of a search engine when databases/schemas are different. When views are 90% the same and just need different rowset renderering etc. Increase the ability of the abstract class, increase the ability of everything that is a child of it.
    3. Factories, anonymous creation and less concrete dependencies throughout your sytem, change the child classes public interface but don't allow that promiscuity to spread from it's siblings where not needed. Though without type hinted return types this relies more on self discipline. Readability can be improved, refacting wise it is a good way to get rid of the for case anti pattern in classes when that for switch triggers different within that class and is a tangle.
    4. Observer pattern, not as useful in PHP as it is very handy managing events. Want to make something else happen when the button is clicked, just register something by interface to the thing the click listener calls and perform the action via distance. Hit concurreny issues late on and add locking that stops stops things from actioning until the action performed by the event is finished. Concurrency issues can be very hard to solve later and it can make a hard thing pretty easy to fix.

    So in those four patterns between them they help with indicating code smells, reusability, promiscuity( very important topic as it interferes with flexibility ) and concurrency. That communicates to me a lot when I see them or feel the need to implement them. Now whether they are done well or not is another thing, that is a human problem and a education problem. Communication can be many things and does not need personal contact or the name of the pattern to ever be muttered.


    Design patterns are simply a tool, one of many, and like any tool they can be used, mis-used, over used and even abused. Using them does not guarantee success, just as not using them does not guarantee failure.
    Completely agree on that one, fan boys can screw anything up. Being able to make well reasoned judgements about approaches seasoned through the years is the only hope of not ending up as a shopping trolley officer for 20 years after forced redundancy at 50.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •