Design patterns and reusable code

PHP
1

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

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

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

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

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. :slight_smile:

6

This is a discussion of software design patterns in the sense of the [url=http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612]famous book by the [URL=“http://en.wikipedia.org/wiki/Design_Patterns_(book)”]Gang of Four.

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

7

I think the time difference and New Years here in England may have something to do with it :slight_smile:

8

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 :slight_smile:

9

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. :slight_smile:

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

10

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

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. :slight_smile:

Cheers,
Alex

12

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. :slight_smile:

13

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

@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

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.

16

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.

17

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

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 :slight_smile:

19

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 :slight_smile:

20

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.