Object Oriented Programming - Java Definition

[Rid123]

I took a year of a low level CIS class through my local college last year (Kansas State University) and I am still in high school. This was pretty much all my school had as far as programming goes, with the exception of a couple somewhat unrelated classes (which I did take). This year, however, there is a new teacher helping with the course. Essentially she doesn't need to do anything but grade, as the professor at the university actually teaches via online lectures. I have been helping her all year, as she has little to no programming experience. I noticed fairly early that the students weren't exactly working as the professor had hoped (they've been making single classes for an entire program, as opposed to multiple classes). I've been trying to help with this, but I'm having difficulty explaining it to them. Thus, I am hoping perhaps someone can give me a simple way to show them the benefits of using multiple classes in Java. I am also wondering if anyone could possibly clarify for me what exactly defining and using a class labeled as interface does is Java?

Thanks in advance for any input!
-Rid123

 

[BillLeeLee]

In good class design, what you really want to do is group together members and functions that are somehow related. So a class describes the behavior of what its instances (objects should have).

Using multiple classes provides some benefits. For example, you can independently test each class to ensure it works properly. You can also use them to modularize programming (build several classes, and use them together in some program together) and aid in developing reusable code.

As for interfaces, in Java, an interface is a type (I guess it's a type) that declares the names of methods/procedures and constant variables, but doesn't actually implement the body of the methods. You can then have a class implement the behavior of the interface. The main benefit of an interface is that you emulate multiple inheritance in Java with them, since you can only inherit from one class, but can implement multiple interfaces.

That's my very brief overview of classes and interfaces.

 

[Stupendous]

What are the students doing exactly? Do they have 1 class with a main method and a bunch of static methods? What type of programs are you having to do in your class? Are they that big? Maybe the programs aren't big enough to demonstrate the benefits of multiple classes. A huge benefit is being able to understand the program, etc. Have you tried showing the class two examples of a program - one example uses 1 class while another follows OO concepts and therefore has multiple classes? Maybe you could show how one solution is a lot clearer to understand than another. You might be able to throw in a little Single Responsibility Principle. It's a very simple principle but as HSer's with little experience they might not see the benefits.

I am also wondering if anyone could possibly clarify for me what exactly defining and using a class labeled as interface does is Java?

This is called polymorphism and it rocks! Here is a simple definition. Here is a rather crude example of polymorphism.

I can provide examples of the many things it can do for you. I use it everyday.

 

[ameoba]

Who needs classes? They're just trouble.

While you're at it, who needs functions? Why not just put your entire program into single 10-thousand line long routine?

If your language lets you use GOTOs, all the better.

 

[bobbydole]

Maybe the programs aren't big enough to demonstrate the benefits of multiple classes. A huge benefit is being able to understand the program, etc. Have you tried showing the class two examples of a program - one example uses 1 class while another follows OO concepts and therefore has multiple classes? Maybe you could show how one solution is a lot clearer to understand than another.

For really simple programs some time you don't need to have a bunch of classes, but if it's required, I would expect myself to learn OO design. However in my first OO class we had a fairly large, fairly complex program that was fairly hard to do without classes, but some what easier with classes. I don't really remember it at all. But I would suggest to the teacher that they give harder homework that really challenged every one in the class!

 

[pinglupanglu]

the best way to see benefits from multiple classes and relations between them is to study design patterns.

 

[InternationalHat]

the best way to see benefits from multiple classes and relations between them is to study design patterns.

No offense, but that's one of the big things that turns people off to OO design and programming. Immediately thrusting Front Controller and MVC on them is going to have them more bewildered than a psychologist in a Dali painting. Not to mention most Patterns are so overused... like people using Front Controller with basic PHP sites???

I'd recommend you start getting them to reuse code. Build on the last project each time and show them how classes work. So one day you create a program that creates an abstract "Monster" class. You show them how to extend it and later assign all the properties, handle any exceptions etc so it's a decent, full featured class. Next time create the player and a rudimentary map. Then get them to build a program that randomly places one of the few Monster classes around on the generated map(really just a 2d array or something). Allow the player to move, have the monsters move randomly. It'd be pretty easy to make a turn-based attack system like Magic:The Gathering and it might get them into the programming style a bit more. Just a thought...

 

[pinglupanglu]

usually when you start studying oop and design patterns you don't start with mvc pattern, but with general approach to solutions, and much simpler patterns (bridge, observer, adapter...).

here is a good book to start with: Addison Wesley - Design Patterns Explained - A New Perspective On Object-Oriented Design.

 

[nameless_centurian]

i would probably just define an object as a user-defined data type.

it's not, really.... but it will help explain why what they are doing is wrong.

...for instance, you wouldn't include a method for string printing in the class that defines integers.

explain it to them as such:

"this class is the definition of a data type, for all intents and purposes. the methods for this data type should be specific for use on this data type."


and then

"for instance, if i have a data type called airplane, and the plane's attributes are engine_size, fuel_capacity, payload possible methods in this class would be

1) print payload
2) fill_tank
3) start_engine

and not things like

1) open_hangar
2) read_map"

then compare it to a primitive data type and say:

"in comparison to integers and our airplain data type ...

if i have an integer, i would do things like:
1) add_one
2) multiply
3) decrement
4) bit_shift

and not things like

1) move_decimal_point
2) print_string

because these methods have nothing to do with integer data types!!!!"

 

[ameoba]

Design patterns aren't a whole lot of use until somebody's got a little experience under their belt and written a few programs. If you've never written over 1000 lines of code, they're going to be needlessly confusing.

Similarly, OO is going to seem like more trouble than it's worth on the simple types of programs you're going to be doing in a CS-101 class - especially in a language like Java that has so much procedural functionality.


Until you get some sort of program design going on, it's really hard to really understand the value of most programming constructs. The 'natural' design coming from most CS-101 students is "chronological design" : You start coding at the beginning of main() and folow the problem description until the end, adding loops where needed - breaking things out into functions is a bonus. Unfortunately, I've seen "enterprise" software coded like this...

The big selling points of OO were :
1) more natural program design
2) greater code reusability
3) simplified colaboration

If you're not doing any of these things, objects seem kinda silly. Design is probably the natural place to start - look into a classic OO design like CRC Cards or something.