Link Details

The blogger isn't half as good as he thinks.

agreed!

Yes and you're not half as good a critic as you think you are. Why don't you try to make a point and argue on the points made in the post? Otherwise your just writing comment graffiti.

@middlec

Now you have done it, you made me register with dzone. The first post hit the nail right on the head, you really aren't half as good as you think you are.

But you want specifics? Let's go then. First off are you rant that developers should know exact definitions, otherwise they are bad programmers. Not that I agree with this statement, but I didn't want to miss out on the lectures from the master of OO so I kept reading. Next what followed is what is best described as a random collection of thoughts and techniques of things you worked on the last month, illustrated with incomplete and buggy code promoting bad practices. At least I now know how to extend my code with 50 lines where 5 would be sufficient.

Next time if you want to make a point, don't try to dazzle us with your knowledge, but stick to the subject and make a point. And when trying to tell about basics, don't write your samples in some arcane framework. Instead use simple and preferable working samples.
,

@billgoates,

I don't know about you, but if I ask my mechanic to explain to me what the transmission does. I'd be pretty bothered if I got "well it makes the uh. I mean when the car, accelerates the uh. Then there's the gears that do uhh." Generally I asked those questions, a coding exercise where they write a small function, an object oriented design problem, and you know what my experience has been so far? That the people who can correctly define what polymorphism and encapsulation are tend to sail through the rest of the phone screen. The people who stumble around, and really don't know. They can't finish the rest of the phone screen. Normally they can't even finish the non-OO coding exercise much less do the object oriented design problem. You'd be surprised how few developers can tell me the difference between ArrayList and Vector. One developer told me synchronized methods would kill your performance, but that he used Vector and didn't know what ArrayList was. Oh the irony. And yet they still right OOD as a skill on their resumes.

I'm not sure what you mean by "buggy code". The code I included was just an illustration of how you can structure your application in a more OO approach as opposed to using static utility methods. It wasn't meant to be complete but describe situations that most web developers would have encountered before. What exact bugs do you see in that code?

What practices are exactly bad? Why are they bad? How do they lead to problems? What would be the proper way to do it according to you?

As for arcane since when has Spring become arcane? Spring is a very popular framework in the Java world.

Sure I was trying to draw from real world examples instead of creating my own. Some of these examples I have are what made me start this blog post. The gist of the article was how model classes (in the MVC pattern) move around the system as opposed to controllers and views which remain fixed in place. By that I mean you don't typically have concrete controller A using methods inside concrete controller B, same goes for the views. However, controller A & B both might use the User object so methods on User would be available to both. So instead of using some UserUtil class, think about how you can put those methods into the model class.

The problem is that you are doing phone screens, so yes, a short definition as reply is preferred. That doesn't mean it tells you anything about someones ability to develop OO. But that wasn't the point, your introduction was good enough to draw attention. But after reading everything, I still don't know the exact definitions, or why I should know them.

Those bugs you can easily find yourself, I'm sure they all are typo's and cut/paste errors. Also I recommend including a constructor in your class 'view'.

Spring is maybe popular in the Java world, but if you writing about Object Oriented Design, as your title and introduction suggested, you cannot expect reader to be familiar with Spring, or even Java.

I am not familiar with MVC or Spring, but thumbnail.send( resposne.getOutputStream() ); (sic) seems wrong.

Assuming that the thumbnail is some sort of generic picture class, I wouldn't want it to know anything about http communication. So I would expect something like this instead: response.sendByteBuffer(thumbnail.getByteBuffer());

Your second example is not entirely clear what you are trying to accomplish, maybe an updated version of handleEvent would have explained it. What I think you are doing, is trying to extend a generic framework with application specific code. That seems to me as OO gone terribly wrong. Maybe it's in OO theory better, but I would advice against it. Such practices make debugging and maintaining code a lot worse.

What I don't understand is your view class. The handleEvent routine expects a ModelAndView, and if you insist on extending the framework, why not inherit from ModelAndView and add the copyParams method?

Polymorphism and encapsulation are basic concepts people who put OOD and OOA on their resumes should be able to create a definition from how they understand it. I'm not looking for a textbook definition, otherwise I might think you read it from a textbook without understanding it. You're right the textbook definitions of these are confusing, but someone who's a practitioner can come up with a more plain English definition without having a lot of trouble. What I'm referring to is a lot of people can't even start to create one which makes me believe they don't really have a good understanding of it. The point of the post was not to educate you on what those definitions are. It was to point out styles of coding that I see over and over from developers that isn't OO, and provide alternative implementations of these by emphsizing those concepts. If you want to know the definition of them look it up, or try and come up with your own. I'll even critique your definition of it if you'd like. :-)

As for your opinion about whether or not a thunmbnail should understand understand HTTP or not. You don't really have to understand Spring to understand the code. I was just trying to place the code in the example with whatever you use as your Controller in the MVC pattern. So I'll try and make an example that more developers can understand. Consider an example where you need to send thumbnails from two seperate Servlets. Or better yet consider that you have a servlet that does it, and you have another requirement that is going to force you to do the same sort of logic from another servlet. And, you need to refactor your code so that you don't duplicate the logic in two different places. You might have some code like:

public doGet( HttpServlet request, HttpServletResponse response ) {
Thumbnail thumbnail = someService.getThumbnail(...);

response.setContentType( thumbnail.getMimeType() );
try {
OutputStream stream = response.getOutputStream();
InputStream istream = thumbnail.getInputStream();
int ch;
while( ( ch = istream.read() ) != -1 ) {
stream.write( ch );
}
ostream.flush();
} finally {
istream.close();
}
}

So what do you do for the second servlet? Copy and paste that code into it? Puuleez. You can't take that code and put it in an instance method inside that servlet and use it from the second servlet can you? Servlet's don't have a way of getting access to other servlet instances. Most people would write a static utility method to handle that. My point is that you're splittling your data and behavior which is exactly the opposite of Object Oriented programming. So what do those servlets have in common? The Thumbnail instance. Why not place that logic there? Thereby placing logic and data together. Wherever instances of Thumbnails show up you have the ability to reuse that code. You'll see how the code now changes to something much tighter:

public doGet( HttpServlet request, HttpServletResponse response ) {
Thumbnail thumbnail = someService.getThumbnail(...);
thumbnail.send( response );
}

Notice how much code you're saving by doing that. Plus it's trivial to reuse that method from any other servlet. Now you might have some sort of problem by letting thumbnail know HTTP or something like that, but I would argue that these points:

1. What are you really saving yourself from by not allowing awareness of javax.serlvet.* api in your model? Aren't you building an application that lives inside a web container? Why not make it easier on yourself and let it understand somethings about HTTP. If you don't your just going to place that logic in some other portion of the system there by separating it from your thumbnail, and forcing all the clients understand how to rejoin your data and logic every time they use it. Make it easy on the clients and give responsibility to the model.

2. You haven't created any more dependencies between the classes than if you didn't do it. I use lots of 3rd party libraries that have knowledge of other libraries that I don't use in my programs. But, that doesn't prevent me from being able to reuse my 3rd party libraries. For example, I don't have to have JSP tags in order to reuse JSP. The same goes for the code we develop. Just because I have HTTP in my model that doesn't mean I can't use Thumbnail in some place that doesn't have HTTP. I just can't call send(HttpServletResponse). But, I could create another send() method that takes in something different that I use in that context. Because I'm passing into the method only that method depends on that API, the other methods are fare to reuse.

3. It's easier to figure out how a system works if I can use my code completion in my IDE. By placing the methods into the model I can figure out how to use it through exploration. If I seperate my logic from my data. I have to have explicit knowledge of that seperation, what it's called, and how to use it. OO techniques help in usability of your model.

As for your "bugs". Again this code is meant only for illustration purposes. It's not fully functional, ready to be copy and pasted into your system. It's meant to convey concepts not source code. I left a lot of code out on purpose because I didn't want to get bogged down in the details that weren't important. Say for example a constructor where all I'm doing is initializing the member variables above. But since you asked:

public View( ModelAndView view, HttpServletRequest request ) {
this.view = view;
this.request = request;
}

As for the View exercise this was just to show another way of extending interfaces without needing to subclass. Sometimes sublassing is not possible especially in cases where you are working with classes through interfaces. If you understand how to use composition and delegation you can accomplish the same thing as inheritance. The other interesting thing about composition over inherritance is the ability to encapsulate details and provide possibly a higher level interface, and hide the details behind it. Maybe an exampel of encapsulation sort of tying back into the premise of the paper of lots of developers don't understand how to define encapsulation much less use it effectively.

I had to down-vote this for no mention of Smalltalk. Smalltalk was *the* OO language. The concept of MVC also came about thanks to it.

Otherwise it's written well :)

Umm thanks I guess. I'd rather have the +1, but believe it or not I was trying to keep the paper some what language agnostic. I know I had Java code examples, but the advice applies to Java, Ruby, or Smalltalk. The difference is that Smalltalk developers usually have this stuff down cold, and don't need a reminder on it. :-)

oh my goodness, someone should run some spellcheck
thubmbnailService.loadThumbnail
thumbnail.send( resposne.
public ModelAndView handlRequest

the examples are poor, incomplete, gibberish. You would have been better off with just explaining it without use of examples. I think you said it best. "If you can't define polymorphism or encapsulation without resorting to examples then you can't write Object Oriented Design as one your skills."

And I disagree that OO is a 'total shift in the way you think'. I happen to think it makes perfect sense and coincides with the way I have always thought about coding. Maybe for cruddy old school bastards who snap 'back in the day when I had punch cards' one liners at me, but not for anyone who at least makes an honest effort to stay current in this fast changing world.

I've done phone screens, and you are correct that many applicants are crap, but not all. Stop being so condescending.

I would argue object modeling isn't that mysterious, but certain techniques like those with design patterns are not. I also think techniques of how you can use encapsulation in your programs to your advantage is not always obvious. Also I remember the day when I finally got how virtual functions in C++ worked. If you got it the first time you read it in your books then hey you're smarter than me. I know that if it took me sometime to figure it out I'm sure others had to struggle with it before they got it too.

So would you say I'm being anymore condescending than remarks like 'I think you said it best. "If you can't define polymorphism or encapsulation without resorting ...'? Or would it be more condescending than saying "cruddy old school bastards..."? Just wondering where on your condescending scale I would fall.

As much as I understand being able to talk-the-talk, the exact opposite is just as true. How many programmers do you know that talk a good game, but suck at programming? Seriously, it took you an entire post to highlight OO, entire books are written on the subject, and you want me to do it on the phone with you in 30 seconds? I will tell you why most programmers choke when you ask them to "describe" encapsulation or polymorphism -- read the definitions yourself. There are numerous occasions when I have read something, and thought, well, someone is trying to justify their PHd, only to have a well qualified programmer demonstrate the technique and I get it immediately.

Well hal, while I'm not asking for them to recite the entire concept of OO back to me. I think you can define those terms pretty well in just a sentence or two without having to create a whole book on it. Sure these concepts do have deep and interesting ramifications for our programs, which is what this blog post was about, but those are separate from the definitions. And, not what I was interested in exploring with candidates. Again I'm not looking for textbook definitions on this, or else I might think you just read the definition without understanding it.

If you can't talk the talk as you say, how am I going to understand your system design, OO models, or points when we get into walking the walk. If you can't explain yourself you aren't going to be much help to a team, and effective communication is having a shared vocabulary that you and I agree to the meaning. Otherwise we'll just keep redefining concepts to each other in order to communicate which is not efficient.