Showing all posts with the category : Design Patterns

Design Patterns

Podcast 7 : Design Patterns Special

30-Aug-2017 in Podcasts Core Java Design Patterns

This week Richard has a rant about everybody's favourite design pattern. You won't believe which one it is. This podcast is slightly more entertaining than the Gang of Four book. Even Grady Booch gets a mention!


Matt:Hello and welcome to number 7 of the All Things Java podcast! I am Matt Greencroft.

Richard:And I'm Richard Chesterwood.

Matt:If you have listened to the first six and you're still with us, hopefully that means we're doing something right. Thank you for staying with us.

Richard:I thought we'd do one and then get bored, so I'm amazed we're still here.

Matt:Well we're going to have to stay doing it for a bit longer, because I've spent quite a bit of time this week getting this podcast onto iTunes, TuneIn, and Stitcher, which has been a little bit of a task. This needs to be worth the effort, so we've got to stay doing at least a few more of these, or I'll be a bit-

Richard:You have to ... No idea how you do syndication of podcasts, but it's something to do with a RSS feed you have to set up.

Matt:Yes. It's a bit of a challenge. It seems from my understanding that Apple defined the standard for podcast RSS feeds and in order to get a podcast onto iTunes, you have to create a feed in the correct format and everyone else piggybacks off of that and uses the same feed.


Matt:Yes, you have to create an RSS feed that has some I suppose name space defined custom fields for podcasts in iTunes’ required format, which if you're doing it by hand, creating a XML file would not be the world's greatest challenge, let's be honest. The only other challenge I think was that you have to supply an image, which must be 300 by 300 pixels or something ridiculous like that.

Richard:You did all of this in Java in a regular Spring Boot app I think.

Matt:Exactly, yeah. The actual website, the All Things Java website is just a Spring Boot app with Thymeleaf and a MySQL backend, nothing special at all. In order to create the podcast rather than coding up some XML, I thought we'd use one of the tools out there to allow you to do it, which is called ROME Tools, I'm not actually quite sure why it's called ROME. I'm sure that stands for something.

Richard:I did know. Okay, we'll put that up in the show notes.

Matt:Yes. It was a bit frustrating because there's a lot of documentation online about, this is what a podcast feed should look like by example. Apple say you must apply with a specification but don't tell you what the specification is. There are a couple of feed validaters out there. The ROME tools documentation, they give you a specific set of classes to build podcast feeds, but the documentation on that is very sparse and is more around how to use it to parse an existing feed rather than to create one. It was a bit of a hackathon trial and error to get it to work, but it does.

Richard:You were musing about should we open source this platform and stick it on GitHub.

Matt:Yeah. I mean, it's on GitHub obviously as a private repository, I was just wondering having ... This is the first thing that I've done on it that I think actually, I couldn't find a good working example of how to build a feed, and thought, well as we've done it, let's make it open source.

Richard:Do a video on it as well.

Matt:Absolutely, to go with it.

Richard:Nice one.

Matt:It would be a bit of a one off video because obviously it's a very sort of bespoke topic but we can do that.

Richard:It is but presumably the Spring Boot would come with it as well, so it's a good working example of a real Spring Boot.

Matt:It is. Why do we, because actually, all that the All Things Java website is, when you look at it, is a blog really. It's a combination of your blog, my blog, and effectively a blog for the podcasts, so there's nothing particularly special about it. I guess we should probably answer questions why didn't we just use something like WordPress, why did we do it ourselves. I guess there were two reasons in my head. One of those was that I like to have full control.

The issue with WordPress is you become very vulnerable to website attacks, all that kind of stuff, but also there's a lot of very minor looking, but customization built in. For example, when we add number seven, this is podcast number seven, but when we add that to the website, obviously we want that to automatically update the RSS feed, which it will do, but also there's a template for us to add in this podcast. We type in the title, the location of the MP3 file that we've created, whether it's on SoundCloud or not, and if so the SoundCloud link. Rather than having to build this up manually, there's a nice sort of designed ... I say nice, not necessarily aesthetically nice, but an easy to use template to allow us to update it very quickly.

Richard:Definitely. My feeling is, I didn't see you developing it or count how many hours you worked, but I, from looking at it from the outside, I'd be surprised if you could've setup a WordPress site as quickly as you did Spring Boot. It probably took a bit longer, but not an order of magnitude.

Matt:Somebody who knows WordPress inside out I'm sure could've done it.

Richard:Then you'd end up with a WordPress site.

Matt:Exactly, exactly. The other thing of course is it allows us then to build and build on it in a way that we know and understand. One of the things that I am working on at the moment is implementing the search feature using Hibernate Search to ... We've got an awful lot of text on that site, particularly the transcripts to every podcast, and that's obviously going to grow. Having a working and usable search facility is obviously important. I'm currently researching that, but actually that would also make a good second video and-

Richard:Actually Hibernate Search was one of the topics in the draft outline for our Hibernate course four years ago now and it was the one topic that fell off due to the schedule and no one screamed for it. It is an absolutely lovely, it's not really a plugin, but it is a lovely implementation. It'll make a great video. You can get it up and running in an hour, it's not difficult, but-

Matt:That's it. I've done the basics, I've got it working, what I'm now doing, and I didn't know Hibernate Search, so I've got an instance of it working locally and I'm now just plugging through to work through what else do we need to know to make it production standard and then again, that can be part of that GitHub repository.

Richard:That's fabulous. This is a good working example of how before Spring Boot came along, if you'd have said, "Let's build All Things Java using Spring," we would've, no, it is going to take you too long, there'll be all this XML. Spring in those days was only useful on big enterprise projects. Now Spring Boot, it's almost as quick as doing WordPress and yet can still do those big enterprise projects. Spring Boot is amazing.

Matt:You know, it's interesting. I was actually sat there at one point thinking back to the days when we used to create website with Grails. The one thing that I missed, and it may be, you can do this with Spring Boot but I haven't found it, is the ability to scaffold pages. The website has, the pages that everyone who looks at the website can see, but there are some admin pages that are allowing this really just to do CRUD stuff on domain classes, and that was a little bit tedious, but that was the only frustrating part of the process.

Richard:I always found the scaffolding with Grails to be, yeah you get up and running with it quickly, but it comes and bites you later. You end up spending more time than you would've done maintaining those scaffolded pages and never a fan of that.


Richard:Anyway, that's what's happening, but we promised that this would be a “design patterns special” this week.


Richard:It's going to be all things design patterns. The reason is we are getting asked by a lot of people, and it was coincidental, we had one just before recording this podcast saying, "Please do a course on design patterns." We never have done, so we'll talk, I think we'll talk about the reasons why we haven't attempted design patterns so far, but I'd like to ask first of all, why do you think we're getting lots of requests for design patterns?

Matt:It's an interesting question. I wonder whether traditionally our core customer base, I think, has been independent consultants. It's the people who are doing jobs that last six months to a year, possibly working either by themselves or in very small teams, and over time, I think that's changed. More and more of our customers are employees working in larger teams. If you also, because more companies are adopting Agile methodologies, they're creating teams that they want to work more in a structured way, they need that shared vocabulary that I guess design patterns give. That's the only thing that's in my head as the obvious answer.

Richard:I promised I wouldn't throw you any curve balls, I know you gave me a very dirty look when I asked you that question, but I was genuinely interested. That's interesting. That's a large part of it. I'm just going to be a bit more direct and say, I think, obviously a lot of our customers are going for job interviews, looking for better jobs and all the rest of it, and unfortunately we have this plague in our industry, which is the whiteboard interview. Utterly ridiculous, probably the worst way of assessing somebody's ability. A lot of our customers are facing a situation where they're being interviewed by some manager “know-all” who will say, "All right then, show me the observer pattern. Here's a whiteboard pen, sketch it up on that board now," which is just hideous. I've been working with these patterns for 15 years, and I don't think I could, cold, off the top of my head, I could probably do observer, certainly some of them, even the ones we use regularly I would struggle to regurgitate in exactly the form that it is in the Gang of Four book. I feel for people in that situation, but I'm not entirely sure we can help.

Matt:I don't think we can help with that, but I guess if we can give people the confidence that they understand the observer pattern, they understand when it's useful, how to implement it, a good example of the existing core Java libraries that is using that pattern for example. That to me means that you can talk authoritatively about it, because even if you can't draw it, you can say, if you've got the, I wanted to say balls, I'm not sure I can say that word, if you've got the guts to be able to do it, you can sit there in an interview.

Richard:We're in charge of this podcast. I don't think it did do iTunes, they may censor for explicit language.

Matt:We have to say whether or not our, one of the fields on the thing is to say whether or not it's explicit. Maybe we should edit that.

Richard:You meant tennis balls.

Matt:I did, indeed. If you have the guts to be able to sit there in an interview and say, "I'm not going to draw it, but I'm going to tell you when you'd use it and why," I'd explain it, I think you'd convince the person.

Richard:We can't mitigate for bad interviewers asking stupid questions can we, but we can do our best to make patterns approachable and friendly. That gets me into, we can't put on the podcast, at least until we do videos, we can't go into technical detail on the patterns. We're not aiming to teach any of the listeners of the podcast how the patterns work, but we can hand wave about them and talk about, we can talk about things on this hour like what are our favourite patterns, what are our least favourite patterns and that kind of thing. I suppose let's go back to the beginning and talk about where patterns come from, what are they, what's the definition of a pattern.

Matt:Go for it.

Richard:I'm in charge of that one am I? I've got right in front of me the classic, it is considered a classic work this, and it's affectionately referred to as the Gang of Four book. If in that interview you say, "Well, according to Gang of Four," then everybody knows what you're talking about. That's common parlance. It just was written by four people.

Matt:Who are the Gang of Four?

Richard:We've got Erich Gamma, Richard Helm, Ralph Johnson, and John, can never pronounce John Vlissides' name. He sadly passed away a couple of years, four or five years ago. I think Erich Gamma was the lead author of this, and the book actually was his PhD thesis, which he turned into a book. The other three were kind of helpers. The foreword is by the great Grady Booch, one of my favourite-

Matt:Who's Grady Booch?

Richard:He had a design methodology called Booch, which was famous for having fluffy clouds, used the fluffy cloud for a class. It'll be forever known for the fluffy clouds.

Matt:I will go and Google that afterwords, we all should do the same.

Richard:He was one of the three people that were employed by Rational at the time to unify their ideas, and out of that came the unified modelling language. He was renowned as being one of the founders of that. Great software engineer though, but I'm going off the point. He didn't do anything for this book.

Erich Gamma is, I'm not sure how, I think he is the lead developer of Eclipse now, has since gone on to be. This book is published is 1995 but was written circa 91, 92ish, something like that. That's relevant because at the time, I'm not sure what the motivations were, but object orientation was starting to push out into the mainstream. I mean, it had been around for decades before then, but suddenly people were starting to use object orientation in real projects. I think it was the inheritance stuff, people just latched onto this idea that we're going to have reuse, the holy grail of software engineering. People didn't know how to design object oriented systems. People were launching into inheritance diagrams and coming up with great trees of inheritance and not finding any benefits or anything like that.

I'm going on about that because it helps to explain where this book came from, it came from an aching desire of people to come on, tell us what structure should we use in object orientation or how should we lay out our code and how do you do good classes and all that kind of thing. It is if you look at the book now, it all feels very odd, because there's a lot of obvious stuff in here. There are 23 so called patterns in here, and actually if you look at some of them, they're just so trivial and obvious it's what you would do anyway, but it needed to be-

Matt:Are they trivial and obvious though, because as Java programmers, that's what we do by default, because this book wasn't written for Java was it?

Richard:That is an interesting, yeah, Java hadn't been invented at the time. It's supposed to be language independent, but it is riddled with C++, which was emerging at the time, had a very short period of being the “in language” and there's quite a bit of smalltalk in there as well, which would've been the best object oriented language at the time. It's supposed to be language independent. I would say that patterns like Facade and Adaptor probably would be obvious to anybody who's written any amount of software. I would've said if you'd have shown me those two patterns when I was 12 working on the ZX Spectrum, I'd probably have gone, "Yeah, okay, I get that." They're not that hard, but they needed to be written down and it needed to be formalised in a way, because it was a bit like the Wild West, it was all up for grabs back then.


Richard:Because they sort of invented patterns, it was one of these community things, it's all community these days isn't it? Discussions on Usenet news groups at the time, people started coming up with ideas for what would be good patterns. I think Erich Gamma says that half of the patterns in the book he'd written, and the others he'd gathered from other sources and so on. That's just putting into the context of the time. I don't understand this book, it became an absolute classic, a total smash hit, and every developer had to have one. This is one of the first books I bought when I started really trying to improve my career. I'd been a hack developer until, I dashed out and got this book to try to impress my mentor at the time, lovely guy called Kenny, who I think you met once many years ago. If Kenny is listening, I won't say a second name just in case it offends him, if Kenny is listening, hello Kenny, good on you, fantastic.

Matt:If you are listening, write in and tell us whether you were impressed by Richard.

Richard:I know the answer to that, he absolutely wasn't. I said, "Kenny, Kenny, look, I've got design patterns," and he looked a bit disgusted at me and said, [poor Scottish accent] "Och, This is no good, it's pristine. If you want to look like, it's got to be beat up." So I immediately went home and started bending, I'm doing this right in the front of the microphone. Now I've started bending the back, you're looking horrified. Give it a good bashing, and I made a special point from then on, I don't know if this fall open at an example, but loads of scribbles all over the book. You've got to show that you've really worked on this.

Matt:It's the coffee stains on the edge that really impress me, Richard.

Richard:The coffee stains, the tears of joy throughout the book. Yeah, I dashed out and got it, I didn't understand a word of it frankly. I think this is a terrible book. That is the bombshell that I'm dropping in this, and that is almost heresy.

Matt:Okay. I'll confess, I came to that book quite late. I first started on design patterns from a much more accessible book, which we might mention in a minute. My sense of it is if you already knew it, it's not that bad a read, but it assumes you have that level of knowledge of their vocabulary, which is to me the vocabulary that I associate with the academic computer scientist, rather than today's modern programmer.

Richard:It was a PhD thesis so it absolutely was an academic book. I think it falls into the trap of, it makes the simple things really complicated, it makes the complicated things totally inaccessible. I know I'm going to be derided for this, because to say that you don't like this book is tantamount to saying, "I'm really stupid. I don't get software." This is probably the end of my career now. It's great knowing you all. I must admit, I read it on the train, it's a while since I picked it up, and I did it read it on the train this morning just to refresh and it was better than I remembered I must say, but what I'm rambling about is, I wouldn't recommend that anybody wanting to get a good start in software and design patterns, any of our customers really, I wouldn't recommend you dash out and buy this book. It's not that great. It never had a second edition. I'll never understand why. It must have sold millions, idiots like me dash out and buy it without even thinking about it. Look at the reviews on Amazon and you'll find a few one star reviews saying overcomplicated, but most of the reviews are, "What a classic work! It's timeless, it will never be beaten!"

Matt:It's one of things that you don't want to admit that you don't understand-

Richard:Exactly, exactly-

Matt:What the name of the guy is who wrote the documentation about REST, you know, "It's very readable."

Richard:Roy Fielding, yeah. Roy Fielding's thesis is very readable for a PhD thesis. I thoroughly recommend you read it. As long as you say that confidently, no one will dare challenge you, but I've never read it obviously.

Anyway, the inspiration for patterns was, and they talk a little bit about it in the book, was they were inspired by a building architect called Christopher Alexander I think, who had written a book on architecture back in the 1970s I think. He coined this term patterns. His idea was that in building architecture, we constantly come up with the same solutions time and time and time and time again. There must be a way of kind of categorising those things that we do in building, and then we can just repeat it rather than learning everything from scratch every time.

He had this idea of writing a book, which contained a series of what he termed patterns, which I hope I'm getting this right, it's something along the lines of given this particular set of problems in the real world, here's a common set of solutions that building architects have reinvented time after time after time. Bay window for example, the bay windows, are they universal and across the world, maybe not. Very common in the 30s in Britain, you have bay windows.

Matt:Yes, I have bay windows, but they're semi-circular sort of front of your house normally, so rather than a flat window, you have, it's not as such a curved window is it, it's a set of windows that form a curve when put together.

Richard:Yeah. I really should've probably read Christopher Alexander's book or flicked through it to revise for this podcast. I'm not sure if bay window, I don't think it is actually in the book, but the reason that's a common pattern, certainly in the UK, is that it gives a wide surface area of light, so it makes your living room very light, but it also creates a kind of place where you can sit and gather. There's always a wide ledge on a bay window or there should be, and you're supposed to sit there and read books and things with natural daylight. That might sound like it's off the point, but the people, Erich Gamma and Gang of Four thought, we must have the same thing in software surely. We keep reinventing the same things, we've got the same structures. We have certain forces in a problem that results in common solutions. That's what they thought they would do, and that's where these 23 came from.

I would argue now, and this makes me sound very arrogant, this was brilliant what they did at the time, but we've got 20 years now of industry knowledge that has gone after it, and the point I'm making is I think a lot of this is now kind of dated in a way and a lot of it has passed into common terminology anyway. At least one of these patterns in the book is a definite anti-pattern and should never be used, so we'll be doing-

Matt:We'll talk about that-

Richard:We certainly will, we'll be doing a course on that, absolutely. I would argue actually if they really were inspired by Alexander, these aren't patterns at all. What they're describing are just really fixes for an inadequate language. The proof of that is if you move away from C++ or Java and you move to even something like Groovy, which is not a million miles away from Java is it, but certainly if you move to Closure or any other language really, you'll find a lot of these patterns invalidated. They have no validity in those languages. That proves that these patterns don't transcend languages. These are fixes for inadequacies of your language frankly.

Matt:Okay, that's interesting. Let's take the observer pattern, purely because we talked about it a bit on the last podcast. For those that aren't clear, we have talked a bit about that pattern. We talked a bit about how that's implemented in Java. The idea of having the ability for two or more objects to communicate effectively, which is one of the things the observer pattern allows you to do, is there a language out there that means you would never need that pattern to be able to do that kind of communication-

Richard:The book talks about, the book basically gives a specific implementation of observer, which uses, they don't talk about interfaces in the book because it was C++ based so they have abstract classes. That's one way of implementing what I would argue is, well, it's just publish subscribe. We always, before Java we'd talk about, we need a pub-sub here. How you implement is, there's a million ways of implementing it, who really cares how it's implemented. One of the important things about the book is it did establish a common language, a common set of terms that we can use, so I now know, talking about observer, I would tend to think you're talking about a specific implementation of pub-sub, but it doesn't really matter.

Matt:Right, okay.

Richard:I know you're working on web sockets at the minute, which we probably won't go into detail just yet because it's still percolating through, but that is effectively, I would say, well that's publish subscribe. You have a server, which has got some information it needs to broadcast to client web browsers. It's pushing that rather than the browser's polling it, which would be potentially an anti-pattern, so it's publish subscribe. I have no idea how that's implemented, I'm looking forward to the course, but it doesn't, I doubt it is, you have an abstract class on the server, which it's not going to be that.

Matt:No, you're right. Yeah, let's say that, that's okay, but I mean it was interesting though for me in that, the web socket example though, because you've got a client talking to the server, the server we're writing in Java, the client's in JavaScript, so you've got two different languages communicating here, and it's the protocol that connects the two together. The client knows nothing about the server and its classes, all it knows is it's got, I suppose the equivalent of interface, because it knows it must have the ability to receive and send a message using this common structure, but it's the, it's not even a formal interface. That's the tricky bit in the way. I guess in the background, it really is, it's got to be. Okay.

Richard:Yeah. I think, for me, I'm being pedantic here. I'm criticising them for not upholding Christopher Alexander's original 1977 idea of what patterns, which is ridiculous really, but to me, a pattern would be something that transcends all languages and would, you will still be using those patterns when you're in your 70s and everything's changed. They will survive lots of things. A pattern would be ... Sorry, you were going to ask a question.

Matt:I was going to say, will we still be talking about them as patterns, or will they just be second nature, this is just how we work?

Richard:To me, a pattern will be low coupling, that's a pattern that we all strive to do. I can't imagine any development in software barring some cataclysmic shift in thinking, low coupling is always going to be something that as engineers, we strive to do. I don't need a massive class diagram to show me low coupling. It's a concept, so high cohesion, things like that. That's not really the point of this, I'm being pedantic. That's what patterns would've been. That's my point. These are more like specific implementations of tricks and techniques you can do in strictly a class based statically typed language. Very few of these patterns would be relevant to JavaScript. A lot of them are irrelevant in languages like Ruby and Scala.

Matt:Yeah, functional languages presumably,

Richard:Functional, yeah, blows most of these out of the water.


Richard:Which is, who cares, it's great, still good valued stuff.

Matt:We are OO programmers primarily and there are plenty of them out there and hopefully they're not going away.

Richard:We are full stack JVM developers, which incorporates lots of functional and lots of, you know. If I were interviewing a developer and they said, "I don't know any patterns," then you'd be very, very suspicious. They should be able to talk about some of them. I would never expect them to sketch out exactly the classic Gang of Four structure as shown in the book. Some of these are horrible.

Matt:You'd expect to be able to say, well, I sort of have a concept of what, say, the decorator pattern is, be able to try to describe it, and certainly at least know when you'd want to use it and come up with an example.


Matt:Yeah, absolutely.

Richard:Yeah, definitely. What would we do on a course then. I think your thinking is we'll have a series of short modules, there'll be an hour video on, this is a problem that we have with a project, here's a solution, and by the way, it happens to be called ...

Matt:I'm struggling right, I'm heavily influenced by the book that I used as my introduction to design patterns was Head First Design Patterns, part of that Head First series, which is the opposite of the Gang of Four book as it is the most accessible. I confess I find it very frustrating because for anyone who hasn't read one of the Head First books, and they are excellent, I'm really not dissing the Head First series of books, they are written-

Richard:Yeah you are!

Matt:They're written in a way, they're full of cartoons and anecdotes and silly phrases and pictures. If you want to just get to the point, if you've got an issue that says, say you're in a team meeting and somebody says, "You need to implement this and you need to be using the decorator pattern. Come back and let's work on it tomorrow," you've got an overnight to read it. Okay, it'll take you 20 minutes to read that chapter, but if you sort of want to get to the nub of it, that's a frustrating-

Richard:Yeah, I can see that, certainly if you were on a ... You're doing a design meeting or something and you've got a white board and I can't quite remember how decorator fits together, then yeah, you'd go straight Gang of Four book-

Matt:To me, I'm just wondering though whether, you know, we've got a tension here in terms of how we teach, which might be why we've put off trying to cover design patterns, which is do we do it the way you just described, which certainly to me feels like a very comfortable way of doing it from our point of view, where you build up to here's the design pattern, which is also I think very much the Head First approach, you don't find out the name of the design pattern until towards the end of the chapter, or do we say, here's a, I'm doing this off my head, it may not make much sense, but here's the concept of what this design pattern is trying to do. Let's have a real example of when you might need this and work through that way. How do we start? There’s a tension there as to, do we try to get to the point quickly and then work through the example, or do we start with the example and-

Richard:Or do both.

Matt:It's difficult isn't it?

Richard:Certainly do both.

Matt:This is certainly on our agenda isn't it, to come up with a series covering the key design patterns.

Richard:Yeah, it has been for a while. It's for exactly that reason. I kind of sense that it's something that, we're best when we can just get into an IDE and start coding. When you have to start explaining deep concepts and you've got pictures and animation and you need to make it visual, it's a very difficult and time consuming exercise that we might ...

Matt:Yes. Some of them will certainly work with, here's a really bad piece of code, a bad way of implementing something, which is where you staredt not knowing about this. Some of them certainly will work as a way of improving that.

Richard:We work with a guy who, an excellent local developer, I probably can't name him because I might drop him in it with his employers or something I don't know, but he was absolutely superb. He did a kind of prototype, that's a bad word, that's one of the design patterns, he did a trial version of a video for us. Unfortunately, we didn't work with him in the end, because as is often the case, he's too busy earning real money out there in the industry. He did a lovely job for us on showing us how we could do builder, the builder design pattern. He really made me, it really opened my eyes to, yeah, right, that's one of the uses of builder that I never quite spotted.

Matt:His was a different approach again, because his was, let's imagine we're on this project together, we're given this project, his starting point was, here's a complete piece of code and let's explore it and understand what it's doing. That's how he started.

Richard:Which is this as virtual pair programmers and it should be exactly our style really. Once you realise that it's, it is a simple case, builder can be quite complicated. Builder's used all over the place by the way, and once you learn builder, you get a very good understanding of why a lot of modern Java frameworks now are always, you're calling a long chain of methods one after the other, all in a single line to construct an object and its builder. Once you realise that, oh yeah, the alternative would've been they had to give you a great big list of arguments in a constructor and because you, well until recently you couldn't have optional arguments in a constructor, you had to overload the constructor a hundred times to cover every single combination of parameters that a client might want to use. Yeah, builder, right, allows you to specify with one long line of code exactly what you're looking for. It was a beautiful way of doing it, he did a great job. Unfortunately we-

Matt:It never panned out unfortunately.

Richard:It didn't go anywhere.

Matt:Okay. I guess it doesn't fit within our normal way of doing courses and our normal teaching style, which is the problem for us really, because it's just that slightly different way of working, which is a challenge. We're certainly committing to do it-

Richard:We need to think outside the box and do it in a different, that's how we do it maybe, and it might be on camera, white board, like we are now, having a discussion.

Matt:We'll have a further think about that.

Richard:So, you can tell me what is your favourite design pattern and I'll tell you my least favourite, how about that?

Matt:I'm going to just say observer.

Richard:I thought you would.

Matt:Only because it's on my head at the minute. It's in my head right now because as we said, I'm working on how to teach websockets. As we said, websockets effectively is an implementation of the observer design pattern. We've got an object on the server which is maintaining some form of state, which various clients are going to connect to, and it needs to be able to tell the clients something in that state has changed and what it is that's changed. That's really what's going on.


Matt:My challenge is, how do you teach that when you can't be sure that the person learning knows that design pattern. I don't want to talk with that sort of language necessarily when it's not quite ... Websockets goes a step further right because it's fully duplex. If you only think about it in terms of design patterns, you miss part of it. That's the challenge for me. I guess this, the ability to at least, it's much easier to explain in terms of design patterns, and I guess that's why I would nominate that today as my favourite, it might not be tomorrow.

Richard:Right. I could be asking you, what's your second favourite?

Matt:I am going to say, I can answer that one actually, because I really do like decorator.

Richard:Fantastic, yeah. Decorator's great.

Matt:Purely because I think it is really clever when you understand it and then you understand for example, we were talking before this podcast about file handling in Java, and when you understand this is why those classes work in the way they do, suddenly you get this, oh, it all makes sense now. The design pattern helps you understand, it makes suddenly all this complicated network of classes that you could be using suddenly makes sense.

Richard:Yes. Unfortunately, our bad this, it's bound to happen I suppose, for some reason sort of general day-to-day file handling in Java is something that we've never covered on any course anywhere. There's some lovely stuff in there, the ability to take any arbitrary object and write it to a network socket or to a file is really powerful. We should've had it somewhere in a course, but it's always fallen through the cracks. That could be a suggestion, one hour on Java file, I don't want to streams now because that's an overloaded term, but Java basic file handling together with the decorator pattern, because it's all built upon that.


Richard:I'm sure it'll satisfy your ... Yeah, sorry, go on.

Matt:I was going to say I'm going to put this back on you, so what's your favourite design pattern?

Richard:Proxy definitely. Proxy's used extensively through Spring framework for example. I would argue that we do have material on design patterns already. If you go through the Spring fundamentals course for example, you're going to get the proxy pattern, which is used all over Spring, but specifically for aspect oriented programming, it's used by Spring Security, and loads of other things.

There's also the template method, one of the classic Gang of Four patterns. If you've used the JDBC template class, you are using the template design pattern. I can't remember actually, I think certainly on the first edition of the course when I was teaching JDBC template, I went all the way back to template method pattern and showed them that and I've got a feeling on second edition, I thought, no, I'm just showing off that I know design patterns and I took it out, but it's all in there.

Proxy's my favourite pattern because again it's clever, it's clever, simple and elegant. I just love the idea that you have a client who thinks they're calling a particular, well, they think they're calling a method on a particular object and they're not, they're calling a stand in object that's sitting between them and the real object. The stand in object, the proxy, is doing its work, its extra stuff. Spring Security for example, if you're securing a domain, we don't do that too often actually to be honest, but if you're securing a domain, not a domain, if you're securing a service in Spring Security, so you're not using servlet level security, you're actually securing the object. You think you're calling the object, actually you're calling the security proxy, which is going to say, are you logged in or not? Well, are you authenticated and are you authorised to call this method? If not get lost, exception thrown. If you are then it just passes the method invocation through to the target and then returns. You're none the wiser as the client. I just love the idea that there's these mechanisms going on behind the scenes. Proxy's beautiful.

Matt:Interesting, okay.

Richard:Absolutely beautiful. Least favourite, I want you to ask me my least favourite.

Matt:Go on then, Richard. What's your least favourite?

Richard:That's a leading question. How did you know I wanted to know? Singleton is an anti-pattern.

Matt:Is this the one you were referring to before?

Richard:I believe we've mentioned it, yes, I said at least one, that is the obvious. Singleton is an anti-pattern, and I can't think of any circumstance where it would be used or useful.

Matt:Let's talk through. What's the singleton pattern, what is the official definition of the singleton pattern and why is it an anti-pattern?

Richard:There is on the front, it's called the frontispiece isn't it, because you're the expert on books, you love classic literature, the frontispiece I think it's called. The first two pages of the book on a hard cover gives a one sentence definition of each of the patterns, so quite useful to learn those if you go no further in the rest of the book. Singleton is, ensure a class has only one instance and provide a global point of access to it. My first moan about that, what are they saying here? I have to ensure classes only have one instance and they kind of miss what they're saying there is, if you want to ensure a class has only one instance, and you want to provide a global point of access to it, then this is how you should implement that requirement.

Matt:Okay, and that is a requirement that we sometimes have, right?

Richard:Absolutely, of course, in systems you have-

Matt:You never want to create what we would call a singleton right, you're not saying that.

Richard:Yeah. The term's okay. It's the implementation that's the anti-pattern. We'll do a Mickey Mouse example just to give some motivation through this. There are better examples, but we've got a system with custom orders and we want to have a class that manages those orders. That's a class that's going to allow us to raise an order, cancel an order, that kind of thing. We only want one instance of the order manager, or you could call it the order book for a company. There's only one order book in a company. You have millions of orders, one order book. There's our requirement. We only want one instance of it.

Singleton, and the reason that I really want to get quite passionate about how bad this pattern is, is that for some reason, this seems to be pattern number one for most people, and it was for me. It's the first one you go to, and I'll confess, when I learned this, I was so pleased with myself first of all for learning a pattern. I went and used it everywhere of course. I loved it. I was an evangelist for singletons.


Richard:I think it's a beguiling pattern, because it's the most code like, it's the one in the book that doesn't have a big complex class diagram with loads of abstract classes. It's basically pseudo code, it's a block of code. I'm a coder, I can understand that. You're flicking through the friendly Head First book there-

Matt:Yeah I was just seeing what they were going to say. I'm trying to get my head around it, I can't remember at all what they say about it, so I was trying to get my head around before you-

Richard:I have a horrible feeling they cover it just as, this is great isn't it, which would be my one criticism of that, but I think that's a great book-

Matt:I was trying to see what they get to, but I didn't know if I would read it in time while you're ...

Richard:Should I waffle on about how it's implemented if you're new to this?


Richard:This is a way of implementing that we only ever want one instance of an object. The first thing you do is you take the constructor of that class and you make it private. If you've got a private constructor, you can't ever call new().


Richard:That's kind of getting you the first part of the requirement. Well, actually, so far, we're never going to be able to correct any instances of this class, but what we can do is put a static method in the class. Am I okay to, I can assume we know about static methods-

Matt:We've certainly covered that.

Richard:It's a method you can call without having to create instances of the class first.


Richard:It's more like a regular function. We'll make that public. In the book they call it, they just call the method instance actually. We could call the method getAccessToOrderBook for example, that's a static method. The implementation of that would just be, if this is the first time I've been called, create a new instance of OrderBook. That's okay, we can do that, because although it's private, we're in this, this static method is in the same class, so that's legal.


Richard:Create a new instance of the object, store a reference to that object for future use, and return that back to the caller.


Richard:If this is not the first time we've been called, then it's even easier, we just return that first object that we created before. I hope that's come across okay-ish on the podcast. I'm waving my hands around, but it's as straightforward as that.


Richard:That's the pattern. By the way, I'm sorry if that's not come across brilliantly on the podcast if any listeners are confused, but at least I covered it in what, three, four sentences. One, two, three, four, five, six, seven, eight pages of this book going through that, it's just ridiculous.

Matt:Let me ask you why you think it's an anti-pattern and then I'll mention the issues that they talk about in the design pattern, sorry the Head First book, now I've refreshed my-

Richard:I don't think it's an anti-pattern, it is an anti-pattern.

Matt:Okay, so why is this an anti-pattern, Richard?

Richard:This probably gives me a chance to criticise the Gang of Four book, which again is not a criticism on the authors, they were inventing something new. The friendly Head First book came along 10 years after that, so they're building on, they had a chance to think things through. The reason the Head First book, okay, yeah, it is cartoony, and that doesn't appeal to everybody, but what they get absolutely right in this book is they don't start just in plucking patterns out of thin air. Here's a pattern, here's another one, here's another one, they're good, aren't they? They start from the principles of software engineering, well, the principles of object orientation I should say, but most of them are principles of engineering generally. They start from the principles and then derive the patterns from the principles, whereas here some principles are mentioned, but not in any kind of coherent fashion.

Manifestly, the singleton pattern violates at least one of the principles, single responsibility principle is the class should be responsible for, we have to be vague here, “one thing”, I'm doing the quote with my hands there, should be responsible for “one thing only”. What does one thing mean? It's a ridiculous thing to say a thing, but as an engineer, you've got to have an intuition on what thing means. The example we gave of an order book for a company, well that's one thing, isn't it? Well it might not be if orders are very complex in this company and creating an order is a complex process of credit control, then all that's one thing. That would need its own class.


Richard:Let's keep things simple and say now ordering is simple, it's create, read, update, delete kind of process, that's one thing. A class should be responsible for one thing only, so we've modelled that as a class. By the way, that transcends object orientation and class module function, who cares, whatever the module in your language of choice is, a module should do one thing only. What we've done with singleton is we've now said, what we're also going to model in this class and we're going to hard code it in, is we're going to model at runtime how many of these is there going to exist in any given context or circumstance. By hard coding into your order management class, you're saying in all circumstances ever, however this system is run, there will always be only one instance of this class, that's the law. That's a requirement that is totally separate, orthogonal, unrelated to the management of orders.

So what, I sound like an academic now, you've violated one of my very important principles, but the reason this became important is not long after this book, there was the next wave of unit testing, automated unit testing suddenly became important. That's what really exposed singleton as a massive anti-pattern was unit testing. I agree, in real production runs of this system, we want one and only one of that order book, but when we're testing that system, we want as many as we need to do tests.

Matt:To do tests, yes.

Richard:If you can only have one, then I'm sure many of you will have been bit by this. If you can only have one instance and you do something with that order book, you put some data in or you do whatever you do in, then that test's finished and you want to move on to the next test, you've got all of the debris from your previous test still stuck in that object. What you need to do is somehow destroy that, and you can't destroy objects in Java. You can't destroy them. You can't destroy an object in Java. If any confusion on that, go to our advanced Java course, look at memory management and all that. You can make an object eligible for garbage collection, but when you've made a singleton object, you've got a static reference to it, which is held in the static reference pool, so it can never be destroyed.

You end up, and this is a proper war story, I'm not making it up, I had been a zealous advocate of singletons, I was working as a trainer at the time in a consultant's project, telling him put singletons here there and everywhere, and then they get me into, "Show us how to do unit tests," and then all of a sudden it was, now you've got to put in destroy methods to undo all of the work, total mess. Total mess. That's only one example of why singleton hurts and is painful, but it's the best example we've ever had. Singleton leads you into that disaster because it violated single responsibility.

Matt:You've convinced me we should be doing a course on this, because certainly the Head First book doesn't mention that either.


Matt:Actually, all it takes about is the issues around-

Richard:Threading, boring. They'll go on about the double checked locking pattern, which you know, so yes, singletons are not thread safe in the implementation they give in the book. You've got to work hard to make it thread safe. Boring, boring, but I mean, that is important. It is important.

Matt:If you're going to use, actually the lesson is you shouldn't be using those.

Richard:Yeah, but it's another example of why, because you've mixed that requirement in with your business requirements, it then gets really complicated when, oh no at runtime, we've got threading issues.

Matt:This is the value we can add then, is it's not just about, here's the design pattern, here's the use case, it's actually, here's when you shouldn't use it. It's the pitfalls with it that, I don't think any other books are probably going to cover that.

Richard:You should never use it because there's no requirement. They're not giving you a pattern there, they're giving you a code implementation, which what do you do if you've got a class that's incohesive? You split it into two. Easy as that.

Matt:Are there any classes within the Java libraries that are singletons that you'd say that is a sensible choice?

Richard:No. It can never be a sensible choice, because if you split the requirement, use your engineering principles, split the requirements up, you would have one class that is your order book, and you would have another class, which is the, this class defines how many instances of order book there should be depending on context.

Matt:Actually I've been sat here while you've been talking thinking about how you would implement this in reality then, so you're thinking something like a factory?

Richard:It's a factory. Exactly. You've just derived from first principles the requirements for a class that says, how many objects am I allowed to give of this. You would code that factory as if we are at production runtime, then make sure there's only one instance of order book. If we are in testing, then dole out order books like there's no tomorrow. Nice, simple implementation. Now my final rant, I promise, I mean, we are coming up to time aren't we, my final rant on this book, this Gang of Four book-

Matt:Don't slam the book in front of the microphone.

Richard:We can edit that out, that's fine. The compressor will get rid of that. Is that factory is so important, so fundamental, and again, Spring framework courses, Spring framework at its core is a factory. In this book, there's factories, oh there's factories, there's two separate methods covering factories, we've got factory method and we've got abstract factory, both of which are really complicated. People are going to laugh, it's not that, they're not complicated, but they're massively overengineered for what we've just described. What we've just described you can implement using a single class, call it order book factory, static method in there with a little bit of logic in it. It will do the job.


Richard:You've not violated any principles of software engineering. It might not look glamorous, but it does the job. Nowhere in this book is that kind of thing mentioned. The friendly Head First book does do that and they call it a simple factory.


Richard:Now, the patterns in here are going much further than that and addressing other requirements. Spring framework for instance is an implementation of factory method, abstract factory, it's really complicated for when you're dealing with huge families of objects in trees. In here, they've put the simple factory and embedded it, hard coded it into singleton, and they've not noticed that they've missed the really fundamental, what should've been a pattern, just call it factory with no fancy stuff on top. I've finished ranting now.


Richard:I'm exhausted through ranting now. That's why I'm saying, there is no, we're often, we're pragmatic programmers to steal a name in both senses. By the way, I would strongly recommend the Pragmatic Programmer book over the Gang of Four book anytime. We're pragmatic with it and we'll often say, keep it simple, do what works, do the most basic thing that works. In the case of singleton, that's not, why would I do that, which it actually, it's a nasty bit of static method complexity, when I could just put that logic in a separate class.


Richard:That's the simplest thing that will possibly work. It's no more complicated than singleton pattern.


Richard:I would never use it.

Matt:Let's take that away in a positive point. There actually should be a singleton design pattern, but it's implemented, it's the concept of saying, you should consider do you only ever want to have in production one instance of this class. The design pattern should be, don't make it so that you can't ever have more than one should you need it, and implement it using a factory pattern is really the, or in one of the other ways.



Richard:Then you might progress that into the classic Gang of Four factory method pattern but you ain't going to need it probably.

Matt:Good, okay.

Richard:We've got, this is going to be a difficult challenge I think, especially, you know, that rant on singleton, if you're in an interview and somebody's asked you to show them the singleton, they don't want to hear any of that, they just want to see the singleton sketched up. I don't know. I don't know.

Matt:If you want to get the job, hopefully you'll be able to say, well, there's issues with this, and if they don't listen, maybe you don't want that particular-

Richard:Well, you sound them out and if they're clearly passionate advocates of singleton, like, oh yeah, singletons, if you're desperate for the job, just ... I don't know. We will do something on it. I would repeat that. We've got lots of pattern material just buried through our courses already. Another way we can handle it is there's patterns all over the standard Java library and usually, I can't think of any counter examples, there might be a few, but usually they're good implementations of the pattern and they're done in the right way and done in the right place.

Matt:I think that's definitely worth referencing back as part of what we do, because as I said, if that then helps you understand how those classes are meant to be used and why they are like they are, it gives you a better-


Matt:At least when you then come and see the next implementation, you've got a prior knowledge of what's going on there.


Matt:I also think it could be helpful for things like, when we're talking about the changes that are coming in Java 9 and modules and this kind of stuff, being able to think of that, if you've got that design pattern background and being able to think of that, particularly the stuff around ... I won't get the terminology right here, but the fact they're doing these modules where you can consume services and these kind of things, they're talking about effectively an interface and a factory that generates an implementation of the interface, you just never seen the implementation. Because they're calling it consuming services, it gets a bit confusing. Again, I think that's another, maybe if we're going to be doing stuff on Java 9, there'll be stuff that comes in as part of that as well potentially.

Richard:Yeah, hopefully. I personally wouldn't recommend that anybody, if you're on a limited budget and you're going for these interviews, I wouldn’t recommend the Gang of Four patterns, it looks good on your desk.

Matt:Buy it secondhand so it's already battered and you can have it under your arm. That's the answer.

Richard:Yeah. I personally love the Head First book, although I confess I read it when it first came out 10 years ago and I've not revisited it. Kathy Sierra, it wasn't Kathy Sierra who wrote the book, but she invented with Bert Bates, invented this system of learning, which they call the Brain Friendly Guide. Their reasoning is all this silliness and all this nonsense is to trick your brain into absorbing the material far quicker than it would do if you were doing it like the way we teach. I'm going to argue they must have got it right, because I read that book 10 years ago, I've never felt the need to go back to it because it just went in. There were a lot of, my colleague at the time as well said, "Rich, I really need to go back to my old code and start reworking it because I've got so much out of this book." It's now 10 years old and they've produced a second edition for the 10th anniversary. I think I would recommend it, I think you get irritated with cutesy things.

Matt:It is a great way to learn about it if you don't already know it. I think if you already have a sense of it or you already know it, there's a frustration element that comes in.

Richard:I had already done, I studied, I'd gone through the pain of doing design patterns and felt I understood most of the patterns, and then went through this and realised there were gaps in what classic Gang of Four had got. I think they, it doesn't look like it, but one of the reviews I saw on Amazon said start with Head First, do the cutesy Mickey Mouse hello world stuff in there, and then do Gang of Four. I disagree, it seems to me to be the other way around. The Gang of Four gets lost and bogged down in nonsensical detail in some places, whereas Head First has an amazing amount of stuff that is missed from the original book.

Matt:It's funny, because I would've gone with the cutesy start with Head First, but then stopped at that point. I wouldn't bother with the Gang of Four. Actually, hopefully in a few months, we'll be saying, "Start with Virtual Programmers, that's the place to start," but we're not there yet.

Richard:Maybe, maybe. As I said earlier, the Head First book starts with principle, six or seven principles of object orientation and then work forward from that, so a much more intelligent way of doing it I think.

Matt:That certainly is absolutely worth going through. That bit wasn't frustrating, possibly because I agree with it because it's the way I was taught, but all that stuff around coupling, around inheritance, composition, absolutely. That's well worth reading.

Richard:Yeah. We'll put links to both books in the show notes.

Matt:Yes, and as you mentioned the Prag Prog book as well. If you think that's a good one, let's link to that as well.

Richard:Yeah, pragmatic, which is more code-like and doesn't cover this sort of thing, but yeah, definitely.

Matt:Let's do that as well.

Richard:We don't have a planned subject for the next podcast, which will be in two weeks time ... No, it won't, you're on holiday I think.

Matt:I am going on holiday, yes.

Richard:I'm not doing a solo podcast, that would be hellish and cruel torture for our customers.

Matt:I happen to know that you enjoy when I go on holiday, because you get a nice week of peace and quiet and probably do no work that week either.

Richard:I shall relax, yes. No, well, I'm learning the, I've finished Docker to module two. It's not released as we're talking, it's going to be released on Thursday, the 31st of August.


Richard:It'll be quite early in the morning, lunch timeish in UK time when it's released. Had a great time with that, and then I'm moving on to-

Matt:Can you give us a quick, what's it highlights, what does it cover, Docker 2?

Richard:That's moving into multiple containers so it's more realistic deployments. You can do almost all of the course regardless of whether you're into microservices or anything like that. Keep it nice and simple, we've got two simple containers until the last two chapters when we take, the microservice deployment that we did on the microservice deployment course, it was so complicated to do that. I was trying to think things simple in that course, but just juggling these EC2 instance, you come to Docker, you just slam it all in its containers and in a few commands, bang, it's running, it's beautiful, and there is lots of websocket goodness in there as well I'm very pleased with the practical. I think it's a genuinely good course, only problem with it, I didn't have time to cover Amazon's ECS service. I'm not that keen on ECS. I'm not happy about having to cover it. I'll do a follow on tiny module, one hour at some point in the next few months. I know there were a couple of people asking us for that, so might get into trouble for that.

I've forgotten the other thing I was going to say. Oh, yeah, I'm just slightly worried it'll go out of date. Docker is moving so fast, they're adding new stuff all the time. People will be asking us next for when are you going to do a course on Kubernetes, which is a sort of orchestration management system on top of Docker and Docker just seems to absorb a lot of the things you can do in Kubernetes so it might be, I don't know, it's a moving target.

Matt:Well done for getting that one finished.

Richard:You've got Java web development second edition?

Matt:Second edition of Java web development, last week, two weeks ago rather, we spoke about whether we should be splitting it to modules, so we have done. Module one is complete, and I say it's complete, it's recorded. It needs editing, post production, that kind of stuff. Hopefully middle of September that one will be released, around about three weeks maybe from now.


Matt:That covers pretty much what I would describe as being the bare bones basics of how web development works in Java before you add a framework on. The perhaps one topic which isn't in module on,e is in module two is Java server pages.


Matt:Module two covers, which is what I'm working on at the moment, covers Java Server pages, MVC, and Ajax, websocket and asynchronous servlets. It's all still Java without frameworks, and actually by the end of module two, that will be that course complete in terms of Java pre-frameworks, so the core underlying, how all of that works. We will be debating whether or not there is a module on frameworks or not, and actually it would quite help me, anyone listening to this, let us know whether you need us to cover any particular frameworks or not. My sense of it is obviously we do a lot on Spring, we've got Java EE, and we could pick one like Play and do a quick start on Play, we could pick, there's loads out there. My question is, I'm not sure if that's needed and if so, which ones we pick. Don't just tell us this is what you use, we'll put a vote in it for it, but tell us this is actually what you use and you struggled learning it. That will be helpful for us I would say. My sort of suspicion is actually that's not a overly asked for requirement, so we may never do a third module on that. We'll see.

Richard:It used to be when there was the framework wars, it used to be, but I think now ... Lots of JavaScript-y front ends calling REST back ends. I'd like to see a course on that. We're debating that. We'll do a double headed course, we'll work on that together.

Matt:Yes, yeah, we are. We've never done any kind of JavaScript type stuff. Interestingly the three chapters that finish off the, actually it might be four chapters, but the very end of this module, second module, the Ajax, asynchronous web servlets and so on, all have some JavaScript in. I've purposefully done raw JavaScript with no external frameworks, purely just to focus on here's the core again of at what's underlying. You're right, nobody in their right mind would not be using a framework.

Richard:I want to see something on Angular and all these sorts of things in our library, it's a big omission. I'd much rather that than we spend six weeks working on a Wicket course when Wicket's great, but does anyone use it anymore? I have no sense of that. A few will use it, but those who use it probably learned it. We're not addressing a need particularly.

Matt:Web one will be out, sorry, part one of web two will be out-

Richard:Three weeks-

Matt:In about three weeks, and hopefully with another three weeks after that we'll have, obviously I'm going on holiday, so-

Richard:Something on Reactive, which is my number one item on my to-do list for the next six weeks pretty much.


Richard:Don't know what that's going to come out like, it's all in the creative, I've got people sitting on bean bags drinking herbal tea, debating-

Matt:You'll have to book our ideas room out, so yeah, where they have pebbles and stones and things, right. Anyway, enough.

Richard:It's been fun shooting the breeze on design patterns and we need a topic for two weeks time, we'll think of ... Not two weeks but it'll be, because you're on holiday.

Matt:I'm on holiday, so it'll probably be three weeks. We'll see how we get on. I'm now going to go and work out how we update our RSS feeds and hopefully get iTunes to pick it up. If you are out there listening through iTunes, make sure you've subscribed so that we can see those numbers go up, because that will help us, and also on TuneIn and Stitcher, they're the other places where you can currently subscribe and hopefully over time we're going to be on more with those, they call them distribution channels, for now will do. Thank you for listening.

Richard:Thank you for being with us again.

Matt:Hopefully see you at the next one.

Richard:See you next time.

Listen via:

Be notified of new posts