Hello, Firstly I am an absolute beginner, not just to Java programming but to any kind of programming so I apologise for perhaps sounding a little dim. I think I am starting to understand objects and what they are all about but if I describe a scenario could someone please tell me if I am grasping it correctly. I am designing an application that takes a image, say a jpeg and resizes it to create a thumbnail, am I right in saying that 1. the image is an object ( with its own class ) 2. the method of resizing it is part of a imaginary rezing object (with it's own class ) 3. The thumbnail created then becomes a third object ( with its own class ) Thanks Sean Warburton
1. the image is an object ( with its own class ) 2. the method of resizing it is part of a imaginary rezing object (with it's own class ) 3. The thumbnail created then becomes a third object ( with its own class )
Objects generally have properties and behavior. Classes allow us to group common properties and behavior, and thereby treat them in a common way. So you've got an image, whose class is, say, Jpeg. This makes sense because one would expect different JPEGs to have a lot in common. Admittably, in this little program you may only have one JPEG. But the point is you're laying a foundation for slightly more complex usage, e.g., consider a program that makes thumbnails out of all the images in a file folder. In that case you'd have multiple instances of the jpeg class. Now what about the thumbnail? Is it also a jpeg? If that's the output format then it would make sense for it to also be an instance of the jpeg class. But if it's a GIF, say, then it's an instance of some other class, 'Gif', say. As for the shrink operation, there are several ways you can go here. One way is as a method of the jpeg class, which produces a shrunken copy of itself, that is, a new object. Another way is to have a shrink method that shrinks itself "in place". (Although keep in mind that in reading the image from a file into your program you've already made a copy.) The third way would be to have objects of some sort of 'ImageTransformer' class. These would be analogous to Photoshop plugins. In simpler applications the first way (simple methods on the objects) is the most common. The second way (modifying objects in place) is also common, but you have to be sure you really don't want the original anymore, at least inside the program. The third way generally only arises in more complex applications (like Photoshop), which have plugins, support for undo, etc.
You can also think of it this way: Even though you're new to programming, as am I, it's easy to understand the old 'proceedural' programming, where a program just runs from top to bottom with maybe a few too many 'goto' statements, as in:
Thinking in terms of objects isn't too difficult as long as you don't get too complicated (easy in the beginning, of course). An expanded approach to your problem above is to write out the problem in 'psuedo-code' (the problem stated in English and broken down into different parts) and then think about what objects are needed to solve the problem. Psuedo-code: 1. Resize a jpeg and display as smaller image a. Get image b. Resize image c. Display newer, smaller image Then you re-write the above to further define it (I'll skip that for the sake of space). After you've done this, you'll discover that you indeed have at least 2 objects and one 'method' - an original .jpeg, a smaller .jpeg, and a method to shrink the first to make the second. If you design this correctly, you'll see that the two .jpegs have a lot in common - in fact, size is the only major difference. Therefore, you'll want to create a class to hold and describe the first .jpeg, and then 'extend' that class to create a sub-class object (for the smaller picture). Like this:
If anyone has any other suggestions or corrections to my work, thank you. This is my understanding as a beginner, but I could be mistaken. But, Sean, assume this is right until someone says otherwise. I'm pretty sure it is - there just may be sexier implementations of this.
-nothing important to say, but learnin' plenty-
Joined: Nov 09, 2003
Thanks Loren and Dave, Dave, I understand exactly what you are saying here, I acually had someone write a Perl application for me to do exactly this and Perl seems relatively simple compared to Java because it seems that it doesn't really matter where you put the code just so long as you link to it in your main application and call the correct procedure. Loren, if I'm right, I think what you are saying is that there is no right or wrong way just more sophisticated ( complex ) ways. I think the lesson I am learning is that Java ( OO languages ) requires far more analysis than procedural languages such as Perl ( I know Perl can be programmed in an object oriented way ).
Joined: Feb 12, 2003
Originally posted by Sean Warburton:
Loren, if I'm right, I think what you are saying is that there is no right or wrong way just more sophisticated ( complex ) ways. I think the lesson I am learning is that Java ( OO languages ) requires far more analysis than procedural languages such as Perl ( I know Perl can be programmed in an object oriented way ).
There are some ways to set-up your classes that would be pretty much always bad, e.g., throwing together a bunch of things that had absolutely nothing to do with each other into the same class. Beyond that, there are engineering tradeoffs. That's part of what makes object design non-trivial. You're right that object design requires more up-front thought, and for a simple program it may be overkill. The payoff comes down the line when you try to modify and extend your program. I should also mention that one approach to getting the object design right is to start out with a very simple design, and over time gradually evolve to something more complex as your needs change.