 You are enjoying the contents? Yes. Are you enjoying the contents? Yes. I have only one slide. The only question is, how you be zooming in and zooming out. And this room is going to be really, really, really smelly because I know whose digestion is not doing good. And because I am going to talk about design smells, basic concept behind it using some examples. So, let's start. I am going to start with Grady Butch. Everyone knows Grady Butch, I hope. He is an Indian Fellow and wrote many books. He is a coordinator of UML. Recently, he wrote this text and he put an analogy between growing cities and software systems in which he says that from time to time cities has to renew or refactor to meet the need of the populace. In a similar way, software system has to also be refactored to meet the need of populace. I like this analogy a lot and I thought, let's dig a little deeper. So, let's dig a little deeper. Yes, this is a map. This is a map where, presently, I live in Bangalore and I am going to tell you a couple of problems I face when I go from my home to my office. This is my home and this is the 200 meter stretch that I need to cover to reach to this main outer ring road. And there used to be a very well-laid road but due to rain and due to a lot of traffic, due to trucks and heavy trucks, that road is gone and currently it looks like this. It's a muddy lane with a lot of path roads. Basically, the point is that the road should be there. There should be a road but right now the road is missing. After some struggle, I come out from this lane and I go to the service lane and then I reach to this particular point. There is an over bridge over here and I need to take a u-turn to come out to the outer ring road. But the problem here is there is no traffic signal. The traffic signal is missing and then what happens? Tows happens. Everybody wants to go first and unnecessarily there is a traffic jam almost every time. That is the underlying problem here is unrestricted access. There is no discipline over there. That's why it's happening. Then I come a little further and then there is a signal popularly known as total mall signal and I want to go from here to directly straight here. And again, from this particular point, I can take eight different directions, eight different turns. Eight legal or? Eight. Eight legal or? Eight legal. Okay, yes, eight legal. That's a good point. Eight legal turns I can take. And imagine now then rest of the eight also can take eight. So essentially eight multiplied by nine, 72 legal directions, legal turns you can take. It looks like to me a hub, hub like road. And actually what happened sometime back is one big truck broke down in the right here in the middle and you can assume what happened. The whole traffic is jammed. Then I go a little further and I see a lot of traffic and what people do, some smart people or I should be saying pseudo smart people, they do like this. And whenever I see it like this, I think in my mind and pause. This is food park, this is for pedestrians. This is not a road. Food park is not a road. But let's come to the point. Why I'm talking to you traffic problems? I promised you in the beginning that I'll be talking about designers but I'm talking to you traffic problems. Why? Is there any point? Yes, there is a point. What I want to say is every engineering discipline has to deal with non-optimal and sub-optimal solutions. And these solutions wallet fundamental principles of that discipline. And those solutions, those non-optimal and sub-optimal solutions are basically nothing but smells of that discipline. And since we are interested in software design, I would like to talk about design smell. So design smell, I don't go in the definition of design smell. The only two things has to be observed here, those are this, that they wallet the fundamental design principle and they negatively impact design quality. Now let's connect the dots basically. I've shown you this missing road. If we talk about passcode domain, road is a basic abstraction. And the road is missing, then the abstraction is missing. In the same way, if we use plums of data or encoded strings instead of hiring a proper abstraction, then the abstraction is missing. That's basically missing abstraction design smell. Let's take an example. People from Java can identify this class much better. There is a class called global in Java. And it provides a method called printStackPlace. What it does? It basically dumps a string in standard output in which it contains information like file number, line number, which class, generated, exception message, things like that. So if you are writing... By the way, it's from Java 1. If you are writing a Java application, then basically you have to catch the string, pass it, use, and then use the information maybe for logging, something like that. Now assume there are many people who might have written code to pass the string and then use that information in some or other way. And now suddenly the format of the string is changed. What will happen? All the application will be... That suggests that possibly this design is not good. Something is missing here. Precisely the abstraction is missing here. And some identified this problem in Java 1.4 and they conducted it. What they did? They introduced another abstraction called StackPlace element. And they introduced another method called that StackPlace. And this abstraction actually providing all the details what you need. Now you need not pass that string and then do whatever you want. Let's move on. Then the next problem I was talking about is relatively unrestricted access. It's very analogous to deficient encapsulation. And what it is, if you have smell, that smell occurs when the declared accessibility of the members of an abstraction is much more than required. Again let's take an example. This is point class in Java and it has two members, that is in Y. It provides get and setters for that in Y but interestingly it also declares as public. So you have multiple ways to get and set these members. Interestingly this is not the only class in Java which has this problem. There are 508 classes in Java, JDK 7 and at least one public field and there are 96 classes which have at least 5 public fields. How many people know about this? Maybe you don't know. The next problem is hub-like role which we've seen that 72 legal directions you can take. Now assume the similar thing can happen in software also that is called hub-like modularization. And when it will happen, when an abstraction has high fan-in and high fan-up, what it means is incoming dependencies and output dependencies are both are high, then we say this abstraction is suffering from hub-like modularization. Then let's talk about an example. This is component class in Java. This class is really nice class, approximately 10,000 lines of code and it has 498 incoming dependencies, 71 outgoing dependencies. So what? The point is if you change here, in this class, so all these 498 incoming dependencies may have to change. Similarly, if any of these 71 classes are changing, then you may need to relook at whether you need to change the component class or not. Again, you don't want to do that. That's why this is a smell. By the way, there is one more class called font in Java, a bad class also suffering from hub-like modularization with high fan-in and high fan-up. This is again a problem. Let's suppose if the road is an abstraction in your design and footpath is another class abstraction in your design, then can you do like this? The road is a base class and footpath is your subclass. Can you do that? You can't do that because footpath is not a road and every inheritance hierarchy has to satisfy the property is A. And whenever the property is getting violated, that translates to broken hierarchy design snack. Let me tell you a very popular example. Many of you might be knowing already. Vector and stack. Stack is inherited from vector. What is a big deal? There is a big deal. Why? Vector is a random access data structure. You can access anything and anywhere. But the stack is a lethal. Last thing first off, which means what it means is if you have an object or stack, then you can call any method from vector and you can access anything from vector, any element in the list, which is violating the semantics of the abstraction. That's why it's a big deal. Actually, I'm coming almost to the end of my talk. The point which I want to convey to you is every engineering discipline has suboptimal and nonoptimal solutions. But as engineers, we need to identify them and software is not an exception. Software development is not an exception in that. In fact, it is more prone to such nonoptimal and suboptimal solutions. Why? Because of intangible nature of the software. The key message I would like to convey is design smells are important. You need to know them, you need to avoid them, and you need to defect them. Here is the reference. These are the examples and all the definitions taken from this book. And unfortunately, I am one of the co-authors of this book. You can find more details here in this site, and these are my contact details. Please feel free to be in contact with me. And the first slide that I showed to you about Geri Buch, that is, he has written a foreword for this book. So the touch is taken from the foreword of this book. That's it. Thank you. Do we have time for a question? Question? Okay, we have. So anybody would like to ask a question? Okay. Tools to detect smells. Yes, there are some, but not all the smells that we have described in this book. We have described 25 different smells. And there are some tools, for example, in C-Sharp and Depend can detect. And for C++ there is a tool called Infusion that can detect. And there are many metrics also that can detect not directly but indirectly. So yes, but there are some tools, but still there is a gap actually. There are many smells that we cannot detect today. Using present set of tools. No, I didn't get your sorry. The tools should detect smells, should be probably conscious. Exactly. Or maybe dogs. That's what it may be. Thank you. Thank you.