Design patterns and reusable code

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.

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

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.

And your point is?

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.

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.

So then do or do not use them, but if you use terms which were not defined by you, such as facade or factory or strategy or MVC. Do not be surprised or upset when someone shares an opinion with you or suggests your implementation is wrong.

Dont share code if peer review bothers you that much. :stuck_out_tongue:

Personally, after having read several books on patterns and a few more on best practices, good design, etc…the more I learn the more I realize the less I know.

I cannot be an expert at everything, so when someone challenges me on my understanding of a pattern or solution, I try my best to listen hard, because the one benefit about being wrong, and accepting that fact, is you learn something new and improve your self in the process.

Even if only half of what someone says is true (in most pattern conversations I see both sides of an argument) you still walk away the wiser, so why not argue about patterns.

Cheers,
Alex

I agree total with Tony Marston on this.

People on this forum seem to use design patterns for the sake of it rather then using it to overcome a problem.

You should always write code to be simple. Remember as I have said before that its harder to write simple code over complex code.

When people tell me that my implementation is wrong I politely point out that it cannot be wrong for the simple reason that it works. What they really object to is that my implementation, indeed my whole approach, is different, and they don’t like “different”.

I have built an entire open source framework around my ideas (see the link in my signature) so anyone can download it and review it. While I welcome constructive criticism please don’t waste your time with puerile insults.

They can be either a hindrance or a help depending on how they are used. Using patterns does not guarantee success just as not using patterns does not guarantee failure. I have seen too many arguments about which patterns should be used, where they should be used and how they should be implemented that I prefer to spend my time in NOT talking about patterns but writing code that actually works. If you ever bother to look at my code you will see that the level of reusability is very high, and all this without the aid of design patterns!

I was trying so hard not to respond… :frowning:

But, you do use design patterns in your framework, radicore. It’s rather trivial to prove, too. Worse yet, you wrote it yourself:

berry@ubuntu:~/radicore% head -n 12 ./includes/std.singleton.php5.inc
<?php
// *****************************************************************************
// Copyright 2003-2005 by A J Marston <http://www.tonymarston.net>
// Copyright 2006-2010 by Radicore Software Limited <http://www.radicore.org>
// *****************************************************************************

class singleton
// ensure that only a single instance exists for each class.
{
static function &getInstance ($class, $arg1=null, $initialise=true)
// implements the ‘singleton’ design pattern.
{

Doesn’t your Default_Table class remind you of something, too? And with the associations and relations in place, it also reminds me of yet another [URL=“http://en.wikipedia.org/wiki/Active_record_pattern”]design pattern. How can you say your not using design patterns? To be honest, I think your claim of high reusability is arguable as well; I don’t think I’ve ever seen such high-coupled code as in your framework, apart from Joomla’s source codes.

berry@ubuntu:~/radicore% grep -Ri “page controller” ./* | wc -l
322
berry@ubuntu:~/radicore% grep -Ri “singleton” ./* | wc -l
223

I bet I could find a lot more occurrences of design patterns in your code, if I’d spend a little more time on it. Just that you don’t want to call them design patterns, doesn’t mean that they aren’t there. Design patterns are abstract theories on how to potentially solve a common problem. You can shout all you want, but elegant solutions for common problems, written in abstracts, so that anyone can implement them and they stay language-agnostic are a good thing. It helps programmers to find a solution to a problem that they face, and that solution is tried and tested. Once you’re experienced, you’ll have your own set of solutions to problems you face and you know how to implement them. You’re reusing the solution, and that could be called a design pattern. Unless, of course, you have an unnatural aversion against them like you seem to.

They don’t provide any reusable code because the patterns are not in code. They are an abstract of a solution to a problem. That solution is very much reusable each and every time you encounter that problem. If your car won’t start because the battery’s dead, there are two solutions: charge the battery, or buy a new one. One might work better than the other, depending on the concrete situation. You have to be experienced to determine which one is better. Also, you can apply those solutions every time you encounter this specific problem, namely a dead battery, no matter what brand of battery, or what kind of car you drive. The solution has nothing to do with the car (or language, or code), but it has everything to do with the solution to that specific problem.

In the end, I think design patterns are a good thing, and every decent programmer will implement them, whether you know the design pattern or not. It’s normal that you use them too, as most design patterns are simply distillations of best practices such as DRY, KISS and “encapsulate what varies”. If you wouldn’t use them (knowingly or “by accident”), you’d be writing software that I wouldn’t touch with a 15 foot pole.

i’ve just looked at your code and it looks very inflexible.

I don’t know what coding standard you are using but I’ve never seen one using classes with lower case names and methods with camel case.

please try to criticise my code!

I get people every day telling me how simple and easy to use it is.

In what way inflexible? I have used it to build an ERP system containing 200 database tables, 300 relationships and 1500 tasks. Most of the tasks are quite simple, but some contain very complex business rules, and all can be handled very easily within my framework. It is as flexible as it need be.

Then you haven’t lived. There is no universal standard regarding class names and method names. Depending on whose code you look at you may see mixtures of uppercase, lowercase, mixed case, camel case, with underscores, and without underscores. Just because my standards are different from yours does not make them wrong.

Please, offer up some of your code for criticism. :cool:

When I say I do not “use” design patterns it means that I do not read about design patterns, decide which ones to use to solve a particular problem, then attempt to implement that set of patterns. I simply design solutions based on my years of previous experience without trying to put a name to any patterns which I may (or may not) use. The fact that design patterns may appear in my code after it has been written is purely coincidental. I state in my articles that the only patterns which I have read about and then attempted to implement are the 3-Tier Architecture and the [url=http://www.tonymarston.net/php-mysql/singleton.html]Singleton. The fact that the [url=http://www.tonymarston.net/php-mysql/model-view-controller.html]MVC pattern appears in my code is purely by accident, not by design. You may look at my code and identify various patterns, but that is no proof that I had those patterns in mind when I wrote that code.

I have a set of pre-written page controllers which are reusable, I have a set of pre-written XSL stylesheets which are reusable, I have a huge amount of reusable code in my abstract table class whch is inherited by every table class, and all database access is provided in pre-writen, and therefore reusable, data access objects. Using my framework it is possible to take a database schema and generate the transactions to maintain the tables without having to write a single line of code - no HTML, no SQL, no PHP. The amount of code which is acually generated is quite small, just small scripts which access pre-written code. How is that not “high reusablity”? Can your framework do that?

Low coupling tends to create more reusable methods, and as my framework contains huge amounts of reusable code it must be low enough. If my coupling was too high there would not be as much reusable code.

Design patterns do not provide reusable solutions, just designs for reusable solutions. There is a subtle difference. When I look at code the only “reusability” I see is when the same code is repeated, so I put it into its own module so I can call the code in that module instead of using a duplicate copy. If two pieces of code are completely different then I have difficulty in seeing any so-called pattern.

DRY and KISS are philosophies which I like to follow, but I don’t follow design patterns as religiously as others. If you can see patterns in my code after it has been written then more power to you, but I don’t think about patterns before I write the code.

Great that it works for you; that’s what software is meant for. I think that what Blueyon meant isn’t about the flexibility of the functionality of the code, but rather the flexibility of the code itself. You’ve got methods which are hundreds of lines long and are written completely procedural. Again; if that works for you, that’s okay, but I’ve discovered a long time ago that it’s better to have small methods to increase the flexibility of your objects.

You might think that’s non-sense, I don’t. Your code is tightly coupled for what I’ve seen from it, and tight coupling decreases flexibility of the code. When code is tightly coupled, it’s hard to replace without doing massive search-and-replace actions, which may lead to annoying bugs. Also, because you tightly coupled a lot of classes together, it’s hard to reuse one single class without lifting in the complete framework. That’s what I meant about your code being inflexible, perhaps Blueyon meant something else.

I know your software metrics are binary; either it works or it doesn’t. Alas, there are other metrics involved in measuring the quality of code and one of those metrics is coupling. Your software is tightly coupled and thus hard to change, and therefor, it doesn’t score well in my eyes. A lot of the design patterns that you denigrate in this topic are meant to decrease the coupling and increase cohesion. Perhaps this is the reason why you don’t like them.

Agreed, coding standards are personal. Some people don’t like my style either, but it’s the way I work best. When working in a team, it becomes a different story and you’ll have to adhere to whatever coding standard decided on.

You can’t base your opinion on the quality of code on some coding standard the author(s) uses, just as much as you can not base the quality on the number of files in a project.

Sure, I’ll try to criticize your code. Not to sound like a twit, but I always enjoy watching the work of other people and compare that to the way I work myself. See if I can find problems in the code. Anyway, I’d criticize your code, if I knew where to find it :wink:

Off Topic:

Oh no, you didn’t just… :stuck_out_tongue:

Again I think tony is right about people needing to name all these patterns.

Design patterns are over rated. They are just common solutions to common problems. If I come againest a OOP coding problem I normally just use my head to work out what is the simplest solution rather than go through a list a design patterns to see which one fits.

Thats not to say I have always been like this. I used to try to use patterns for everything after visiting forums like this one for to long.

Just programme in OOP. Reusability is really down to years of experiance of knowing what works and what doesn’t. Reusability could mean infexability so its really down to experiance.

Agreed, some people act as if design patterns are the holy grail and they try to fit in every design pattern they know of. That’s not very practical, as it tends to make your code (much) harder to understand, and since I’m rather dumb and lazy, I like code I can understand easily. However, that’s not the reason Tony has started this topic, so although you seem to agree on the general consensus (“design patterns aren’t silver bullets”), your arguments differ. His argument is: “If design patterns do not provide any reusable code then what is the point of using them?”

Saying that one should not use design patterns because you can not reuse the solution after creating a specific solution to a specific problem is strange, as the context will be different in each situation, thus the solution is different just as well. Yes, you have to create a solution to your problem, you will have to anyway, regardless of whether you call them design patterns or go against the rest of the world. If you still think that design patterns are worthless, even though the resulting code is clean, has just as many lines of code as another solution to the same problem, and has the downsides documented for you, you’re just not good at abstract thinking. Seriously.

Still, you’re better for it. Now, when you run into a problem, you’ll at the very least know of one solution, regardless of the fact that it’s a design pattern or not. You use them, I use them, Tony uses them. I’m just the only one of the three who dares admitting to that.

No, I don’t go through my book of Patterns of Enterprise Application Architecture when I encounter code in which there are a few candidates objects to create, which all adhere the same interface, and the one I want is dependent on, say, a simple string variable. I just factor out the creation into it’s own method and let that method decide. If multiple objects need to create that object based on that simple string variable, I factor out the method into it’s own object.

Guess what? That’s an implementation of the Factory pattern. Did I know that from the start? No, I just refactored in the most DRY and logical solution, and the design pattern was implemented. I could throw my hands in the air and shout: “oh dear, that’s a design pattern I’ve just incorporated into my code, will it be reusable?”, or I could just accept the fact that the rest of the world already knows this solution and calls it a factory.

I’ll document my code and call it a factory too. Not because I felt the urge to implement a factory, but because it’s the best thing to do at that time, in that situation, according to my experience and acquired knowledge of best practices. I wouldn’t have known it’s a factory if I wouldn’t have known design patterns. I would’ve come up with the exact same solution though, eventually, but it’d simply take longer. Knowing what “pre-discovered” solutions to a problem there are, will help in your day to day routine.

It’s about learning, mostly from the ones before you. You can look the other way and try to figure out on your own, or simply just read a catalog of design patterns for a change. The nett result of the latter is that you’ll be wiser from it, the former is that you’re doing a lot of thinking work already done. You shouldn’t stop thinking and implement design patterns blindly, and you should think about the implications they will form, even if the implication is as simple as readability.

No, we’re are not mindless drones that should be listening to everything authors of design patterns have to say, and I actually have critique on some of the patterns I’ve read about. Still, ignoring the patterns is ignoring ideas to solve the problems that you’re facing. I’ll let you decide if that’s a good idea. I, myself, do read about patterns, and I don’t incorporate them until I think to myself: how the hell do I solve this? Oh wait, didn’t I read a piece on a problem that somehow resembles this problem? Ah yes, it was $pattern. Do I like that solution in this particular situation? Great, let’s solve it that way. If I don’t like the solution described, I find another solution.

There are exceptions, too. For example, I use the Model View Controller pattern per default if the application is of a well enough size. I use my own implementation, and my own idea’s about them, because that’s what works for me. The pattern itself has no implementation, so an (or more importantly, my) implementation can not be wrong. It could, however, be inefficient, inflexible, or hard to comprehend. All the moaning about who has the “purest” implementation is non-sense. There is no implementation, so it can never be the purest. It can be the most flexible, the most readable, the fastest or the most loosely coupled implementation, but never the purest. Mileages vary, depending on a lot of external factors.

So, in conclusion, I’d have to say: make sure you know some of the design patterns, or at least the ones most frequently used in your languages, make up your mind about each of them, carefully balance the need to implement them and only do so when called for. You’re simply broadening your scope of solutions, with knowledge of those solutions, including their up- and downsides. Ignoring the solutions others before you have explored and documented, you’re a fool. I believe people should stop whining about design patterns and who’s implementation is purest, because you’ll now know it’s not true anyway. Just use what you need to, in the way that is right for you and don’t use the rest.

Yes. And all those years of experience from N of the greatest minds in OO programming are distilled and described in books about design patterns. Think twice before you say it’s overrated, think three times before you claim they are useless and shouldn’t be used. Knowing design patterns is gaining knowledge of solutions in a very structured manner. You could try and pretend you solve everything yourself, but you’d still have to find out the downsides of your solutions – the hard way. And the ironic part is that if you come up with a really good solution, chances are that it has already been done and documented in a pattern, before you thought of it.

Reusability and flexibility are actually closely related in the world of OO programming. Reusability is achieved by making sure that objects can be reused in a different context and by other objects. Flexibility is achieved by making sure that you can use (or, inject) a different implementation of the same interface. Before you have flexibility, you must first have reusability. It’s that simple, really.

If you think about it long enough you should realise that a method is nothing more than a procedural function which is wrapped in a class. It is still procedural. The idea of encapsulation in OO is that you take all the operations (functions) and variables concerned with an object and put them into the same capsule (class). There are no code differences between a function and a method - they are both procedural.

I discovered a long time ago that if you take a large function and break it down into smaller function all you end up with is a lot of small functions, which are harder to manage. I’ve seen what happens when a dumb programmer takes a large function and splits it after every 20 lines “because the standards say that no function should contain more than 20 lines”.

The only reason to break up a function into smaller units is if any of those units needs to be called either independently or conditionally.