Classes vs Objects

[Steve Keystone]

I've read some of the prior posting on this subject, but I'm still confused (and didn't want to dredge up old posts). I have a simple question, but for the life of me, every answer I get confuses me even more. Explain Classes vs Objects. I'm referencing this off of page 31-35 Head First Java 2nd Ed.

In the case of the Dog class, how do I define/explain things about different breeds? As I understand it, Dog is the class and the different breeds are objects. So, if one of my breeds is Pug, how would I pick out a blind pug? Do I make a separate object for BlindPugs even though they're not a breed, but a variation on one? If I took the dog analogy one step further and replaced Dogs with Seats, it brings me to the next bit.

I'm looking at practice programs and the one that comes to mind is the "seat reservation" one. Everything makes sense when considering 1st class/2nd class, aisle/window seats. But, the minute you throw something random in like "seat that just had a drink spilled in it" throws my whole thinking and train of thought out the window.

[Dave Tolls]

For a seat reservation system why would you want to note a value of "drink spilled on it"?
That has very little to do with a reservation application.

[Steve Keystone]

Maybe "dirty seat" would have been a better choice of words. I see that many of these programs use 1st class/2nd class or aisle/window or something similar. But what of non-standard choices? I don't want a seat that faces backwards or is soiled or who's in-flight entertainment doesn't work. The standard choices are too black and white. Based on that, how does class/object affect those instances?

[Daniel Cox]

Steve Keystone wrote:Explain Classes vs Objects.

A class is a specification that defines the attributes and behaviours of a real thing, for example, if you are a car maker, you may design a Car class that specifies the attributes and behaviours of every car you produce in your factory. The specification (class) may say that every car will have 4 wheels and two screen wipers (attributes) and every car will be able to accelerate and stop (behaviours). Each car (real thing) produced based on that specification (class) is an instance of the class. Each car is an object that has the attributes and behaviours specified in the class.

Steve Keystone wrote:In the case of the Dog class, how do I define/explain things about different breeds? As I understand it, Dog is the class and the different breeds are objects. So, if one of my breeds is Pug, how would I pick out a blind pug? Do I make a separate object for BlindPugs even though they're not a breed, but a variation on one?

A Dog class may specify the attributes of a dog including its breed, colour, age etc. It may also specify values for these attributes. It may also specify behaviours that can modify these attributes. Every dog created from the Dog class will have the attributes and behaviours specified in the Dog class. You can give a dog any attribute or behaviour you like, for example, you can design a dog that is able to change its breed from pug to poodle or change its temperament from affectionate to aggressive.

[Henry Wong]

Stuff like this happens all the time. There is no way to model the perfect class design... and in my opinion, it is probably not a good idea to try to guess what change requests will be coming down the pike, or even expose your class hierarchy to your customers.

So, in this case taken as an example, if my client asks for the ability to deal with seats that have coffee spilled on it... that is merely a feature that you need to support. First, talk to your client to get more detail; I will speculate that they just want the ability to enable / disable the seat from being reserved, and the ability to note "why".

Second, does this really need a class design change? maybe, but perhaps not. Remember that, at this point, you have already built the reservation system (and this is a change request). So, you need to balance getting the perfect design, with changing core stuff that requires a lot of changes to the upper layers and QA testing, with timelines to make changes (which affect customer satisfaction), etc.

Henry

[Dave Tolls]

Steve Keystone wrote:Maybe "dirty seat" would have been a better choice of words. I see that many of these programs use 1st class/2nd class or aisle/window or something similar. But what of non-standard choices? I don't want a seat that faces backwards or is soiled or who's in-flight entertainment doesn't work. The standard choices are too black and white. Based on that, how does class/object affect those instances?

OK, if "dirty seat" is a valid selection then a seat will have to be marked as such in its model.

But I have not seen a single reservation app (and I've worked on one or two, as well as used several) that would have that sort of selection as part of the seating model.
The best you'll get is some sort of write-in request as part of the booking.

Take train seats.
I have seen apps that allow you to select direction of travel (if applicable) as "back to engine" or not.

It's all about what is considered a relevant thing to allow someone to select for the application in question.

Take the "in flight ent not working" one.  Any customer booking will expect a functioning seat.  That's part of what you are paying for.  So why add a checkbox into the booking application?

[Steve Keystone]

Henry, thanks for the reply, but i'm still learning to crawl here. Most of what you have said went right over my head, as is the case with most java books I've looked at.

My brain is my biggest obstacle here. I hate to use a Seat Reservation example, but its the best and one of the few examples that would fit my question. I cant quite wrap my head around what makes something an object. My limited understanding says "Seats" are a class. But what do I do when each seat has different attributes? Do I make a subclass of seats? The example that really wracks my brain is the one with 1st class/2nd class seats, of which some face front, some face rear. Some have tables, some don't. Some are aisle, some are window. They are not laid out in any logical format to where you can say "every forward facing 1st class seat has a table". At this point I cannot fathom how to even begin sketching out a plan.

[Dave Tolls]

class Seat {
    private String seatNumber;
    private TravelClass travelClass; (maybe enum, FIRST, SECOND?)
    private boolean backToEngine;
    private boolean hasTable;
}

That's just picking up the attributes of a Seat that you posted, presumably because you consider them an important part of the model.
The TravelClass could be an enum, or quite possibly a class if it has a bunch of logic around it and you don't want to restrict the types.

ETA:  though I missed out aisle/window.

[Steve Keystone]

Ok, I think we're going somewhere here ;) Seat is the class, yes? And the attributes identify the variables (for lack of a better word)? So there would be no need for subclasses for First, Second, etc?

[Steve Keystone]

I apologize for double posting, but couldn't find where to edit my post. I'm sorry if it seems I'm being difficult, its just that I have difficulty with comprehension these days (TBI & PTSD). I have read through the Java for Kids book and find it confusing as well. You may think you're being condescending, but I'd actually prefer if you could explain things so that an 8 year old could understand.

[fred rosenberger]

A Class is a blueprint.  it lays out the structure and tells you what an object can do.  Once you have a class, you can create a "sub-class".  That is where you say "i want to start with this other class, so give me all that for free, but then make these changes to it".  So you can create a Mammal class that has attributes common to all mammals.  But then you can make a Dog subclass, and add the special things that only a Dog would have that a mammal wouldn't.

At this point, you have the descriptions - the class only.

When your program runs, you would create one or more specific Dogs.  You would create a Dog named "Spot", and another named "Fido", and maybe a third named "Scooby-Doo".  Those three specific instances of the class are Objects, built from the Class you defined.

[Knute Snortum]

Steve Keystone wrote:Ok, I think we're going somewhere here ;) Seat is the class, yes?

Yes

And the attributes identify the variables (for lack of a better word)?

Correct

So there would be no need for subclasses for First, Second, etc?

Again, correct.  Let's look at some more specifics:

class Seat {
	// Fields, these are the attributes of Seat
    private String seatNumber;
    private TravelClass travelClass; 
	private boolean backToEngine;
    private boolean hasTable;
    
    // Getters, setters
    // This is one way to set the attributes of Seat 
    public String getSeatNumber() {
		return seatNumber;
	}
	public void setSeatNumber(String seatNumber) {
		this.seatNumber = seatNumber;
	}
	public TravelClass getTravelClass() {
		return travelClass;
	}
	public void setTravelClass(TravelClass travelClass) {
		this.travelClass = travelClass;
	}
	public boolean isBackToEngine() {
		return backToEngine;
	}
	public void setBackToEngine(boolean backToEngine) {
		this.backToEngine = backToEngine;
	}
	public boolean isHasTable() {
		return hasTable;
	}
	public void setHasTable(boolean hasTable) {
		this.hasTable = hasTable;
	}

}

enum TravelClass {
	FIRST, SECOND;
}

public class SeatDemo {
	public static void main(String[] args) {
		// Create an object from the class Seat
		Seat firstClassSeat = new Seat();
		// This specific object has an attribute of First Class
		firstClassSeat.setTravelClass(TravelClass.FIRST);
		
		// Create another object from the Seat class
		Seat secondClassSeat = new Seat();
		// This object is a Second Class seat
		secondClassSeat.setTravelClass(TravelClass.SECOND);
	}
}

So the class can be thought of as a template and each object a construction from that template.  The exact wording is that an object is an instance of a class.

[Steve Keystone]

Head First Java uses the Example Shape (p.32). Subclasses are Square, Circle, Triangle and Amoeba. That, I understand, as well as the dog examples Fred has given. But what about when there is something that doesnt quite fit, like an obtuse triangle, whose sides aren't equal and wouldnt fit within the Triangle subclass? Do you make a sub-subclass or do you make a new class?

If I jump back to Dave Toll's example, could I put loads of attributes in the Seat class and just answer yes/no to them? I mean if i'm looking for a rear facing 1st class seat with a table, but is not a window seat. Boolean?

[Knute Snortum]

Steve Keystone wrote:Head First Java uses the Example Shape (p.32). Subclasses are Square, Circle, Triangle and Amoeba. That, I understand, as well as the dog examples Fred has given. But what about when there is something that doesnt quite fit, like an obtuse triangle, whose sides aren't equal and wouldnt fit within the Triangle subclass?

Well, a well-written Triangle class would include the ability to describe an obtuse triangle, a equilateral triangle, and so on.  You could subclass Triangle into these other specific types of triangles.

Do you make a sub-subclass or do you make a new class?

You can subclass as deep as you want (I think.  At least, very deep).

If I jump back to Dave Toll's example, could I put loads of attributes in the Seat class and just answer yes/no to them? I mean if i'm looking for a rear facing 1st class seat with a table, but is not a window seat. Boolean?

Yes you could (and they would be type boolean), but some things wouldn't be just yes/no, like the type of the seat (first class, second class, etc.)

[Steve Keystone]

Thank you very very much Knute!I'll have to look more into ENUM as I've not seen that one before.

[Fred Kleinschmidt]

Steve Keystone wrote:what about when there is something that doesnt quite fit, like an obtuse triangle, whose sides aren't equal and wouldnt fit within the Triangle subclass? Do you make a sub-subclass or do you make a new class?

One always has to decide how to design a class, and to decide whether a special case is different enough to warrant creating a subclass, or whether there should just be an attribute of the original class that can be used to describe the difference.

For example, let's take a square. Should we have a class Square as a subclass of Rectangle? And should Rectangle be a subclass of Parallelogram? And Parallelogram be a subclass of Quadrilateral? And where do Rhombus, Trapezoid, and Kite fit in this scheme?

Quadrilateral could be the only 4-sided subclass of Shape, with attributes of sideLength[4] and angle[4], from which we can deduce whether a specific instance of Quadrilateral  is a square, parallelogram, rhombus, or whatever. In the same way, Triangle can have sideLength[3] and angle[3] as attributes, from which one can deduce whether that triangle is obtuse, equilateral, or whatever.

[Junilu Lacar]

Been watching this thread and notice that it has gone down a very familiar path: the path that turns design into an academic exercise that's lacking in context.

Context is the key consideration for designing objects/classes. What specific problem(s) are you trying to solve? What has been done before to solve that problem?

Go back to the reservation system. Think of the last plane reservation you made online. I did one just a couple of weeks ago. Here's how my experience went:  I picked my origin/destination, the date, and preferred times for the flight.  I got a list of choices. I picked one of the airlines and a specific flight. I picked out my seat assignment (no indication about the seats other than that they were available or not or if they would cost more as an upgrade). I got to review my selections, then confirmed my booking. I got a confirmation email, which I was able to forward to TripCase. A few minutes later, I got a notification from TripCase that my itinerary had been received and my trip countdown clock started ticking away.

Steve, I realize that you are just trying to practice OO design / analysis but if you really want to do that in a way that reflects how you would do it in a real development scenario, I think it would behoove you to set up a realistic context in which you can set boundaries and parameters for your design. Without a context or point of reference, you'll just be floating aimlessly around in a big open ocean of "what ifs".  The usefulness of Object thinking is not so much in creating program entities that reflect real-world objects but rather in its ability to help you organize behaviors and the data that they depend on in such a way that makes sense for them to be lumped together. Many well-designed objects/classes don't actually have real-world equivalents but they still make sense because conceptually, they can be thought of things that exist and behave as a single "entity".

I think it's unfortunate that techniques like CRC cards seem to have fallen by the wayside. CRC cards and role playing the responsibilities and behaviors on them is a great way for a team to see how their design ideas might play out in the code and it gives you a good idea of the context that your objects have to operate in. I hardly ever hear of anyone using CRC cards any more though.

[Junilu Lacar]

(continuing...) So, when I see the kind of discussions you've had so far in this thread, it reminds me of the pitfall of starting your design thinking from specific objects without regard for the context. How did we get to the decision of making Seat a full-on object rather than just a field on some other object, say a Reservation object? Is it realistic or worthwhile to worry about "dirty seats"? Do airlines even care to pay for that kind of a feature in their reservation system? What are the logistics for updating the system to reflect seats that are dirty or not? Is it realistic or practical to do that? Could the development effort be applied to add another, perhaps more valuable feature in the system?

[Steve Keystone]

Junilu,

Thanks for the input and yes, I have heard the term CRC cards, but more in terms of design (the bigger picture), not problem solving. I know just enough about java to get myself into trouble. When I was younger I struggled in math. My teachers always said "don’t worry, it will come to you as time progresses", well, it didn’t and I ended up failing most classes above basic math. The same has started happening with Java. I've done Code Academy, Tech Rocket, countless mobile "Learn Java" apps and even a few basic Java courses. The most common failure is that they give one or two examples and then move on. When I then encounter anything beyond those 2 very generic examples, I get confused. We all spent ages learning our ABC's and practiced writing letters thousands of times, yet objects/classes receive less than 2 days in any class (that I've taken). Don’t even get me started on Main and method.  

At this point I have found that Dave Toll's and Knute's answers have been the most helpful. We've all heard of the Dummies series of how-to guides, well, I need something simpler.  

In regards to lacking context. Context is exactly what I'm seeking. If I have to find 1000 examples of objects/classes (and possible scenarios) to fully comprehend things, then thats what I will do. What is the point in moving forward if I only "sort of get it"? I wouldnt accept it in my kid's learning, so why should I?

[Dave Tolls]

Junilu Lacar wrote:How did we get to the decision of making Seat a full-on object rather than just a field on some other object, say a Reservation object?

Having worked on these systems there's more to a Seat than just an identifier, at least for airlines and some trains.

As soon as the requirements, albeit ones plucked out of thin air by the OP, decided that a seat also needed to show what direction it faced and whether it was window or aisle, and it had a travel category then something needed to map that.

As I said above:

That's just picking up the attributes of a Seat that you posted, presumably because you consider them an important part of the model.

There are things that can be shifted around.
Travel category, for example, might be stuck on a carriage/section basis, and is therefore not an attribute of a Seat except by association.  I think OTA is structured like that, IIRC.
But things like "emergency exit", "bulkhead", "aisle/window/mid" are.
If they are important to the process at hand.

[Daniel Cox]

Steve Keystone wrote:When I was younger I struggled in math. My teachers always said "don’t worry, it will come to you as time progresses", well, it didn’t and I ended up failing most classes above basic math. The same has started happening with Java.

That's interesting! In my experience, people who don't gravitate towards mathematics tend not to gravitate towards programming. I'm not saying that it doesn't happen. I've heard of people with a fine art background who are excellent programmers. Anyway, I think that the key is persistence. It might take a while to get your head around certain programming concepts but once you do, it stays with you for life. The ranch is a good place to help make that happen. I like online learning platforms like Code Academy and Tech Rocket but IMO nothing beats a good book (and the ranch   ).

[Junilu Lacar]

Steve Keystone wrote:We've all heard of the Dummies series of how-to guides, well, I need something simpler.

Well, then you'd better get used to disappointment. Software development is complex and complicated because any non-trivial problem you try to solve with software is going to be complex and complicated. There's just no way around that. If it were otherwise, then many more people than there actually are would be capable of doing it professionally. In almost three decades of doing this for a living, however, I have found that less than 50% of people who develop software professionally are halfway decent programmers. And that's being very generous.

One of the things that differentiates good programmers from those who aren't is exactly their ability to see the "bigger picture". I was very lucky in that the professors I had in school also did professional software development on the side. They injected a lot of their real-world experience into their instruction and therefore emphasized things like tight cohesion, loose coupling, modularization, and clarity of intent. These are things I don't see emphasized to anywhere near the degree it was when I was studying, even in my son's programming courses at a major university here in the US (I got my B.S. in Mechanical Engineering in the Philippines, with a couple of years worth of credits in Comp Sci thrown in). I'm aging myself here but I started out back in the days of procedural programming and structured analysis and design. OO wasn't even a thing yet back then and Java was still a few years away from being created.

Steve Keystone wrote:What is the point in moving forward if I only "sort of get it"? I wouldnt accept it in my kid's learning, so why should I?

Therein lies the rub. As I said, software development is complex and complicated so none of us actually "get it" all; we all only "sort of get" software development. The only difference is how much "sort of" encompasses and how much of "sort of" you're willing to move forward with. Any programmer who thinks they know it all is either too arrogant/ignorant to see his/her own shortcomings, or at a point where they are no longer capable of learning. If there ever was a profession where continuous learning was a key to survival, it's this one. Good programmers never stop learning.

I've been watching a lot of WWII documentaries/docudramas recently and one thing I've noticed is that the officers keep yelling at their "boots" to "KEEP MOVING! GET OFF THE BEACH!!!"  That's another differentiator between good programmers and those who just flounder about. Good programmers are always moving forward, no matter how much they screw up or how daunting the road ahead looks. Actually, I believe that's the only way to actually get really good at programming: just keep screwing up and keep learning from your mistakes and experiences. Professional programmers often have titles of "engineer" but the work and learning process is really more fitting of the title "Mad Scientist," which is why I think Martin Fowler's title of "Chief Scientist" at Thoughtworks, Inc. is very cool and very fitting.

Steve Keystone wrote:In regards to lacking context. Context is exactly what I'm seeking. If I have to find 1000 examples of objects/classes (and possible scenarios) to fully comprehend things, then thats what I will do.

Then I suggest you start by not thinking that the "bigger picture" and design thinking is outside the reach of your capabilities. Programming is all about design and the big picture. You won't make much progress by thinking "in the small" of specific objects in isolation; you've already seen how little progress you make by doing so. That's not the kind of context I'm talking about. Start casting your net farther and wider. You'll never solve a jigsaw puzzle by just analyzing each piece individually. You have to start trying to join pieces together to form larger chunks, then join those chunks with other chunks until you have see more and more of the "bigger picture". Objects don't live in isolation; they exist in a certain context and they interact with other objects. The community of objects and the problems that they solve together is what gives you the context that allows you to "sort of" get a better idea of what the bigger picture of programming is all about.

If you're up for it, if you're really interested in learning more, then pay us a visit in the Design Forum (in the Engineering section of the Ranch). Poke around and read some of the older, longer threads I've been in (excuse the shameless self-promotion). You may find reading through them daunting but there are some good NCOs who'll take care of you over there and help you get off the beach safely and into the jungle where the real fighting happens.  

Good luck.

[Knute Snortum]

I've done Code Academy, Tech Rocket, countless mobile "Learn Java" apps and even a few basic Java courses. The most common failure is that they give one or two examples and then move on.

May I suggest HackerRank as a possibility then?  What I like about it is that when you solve a problem, you can see how everyone else solved it.  I found this a humbling but very beneficial experience.  Where my solutions might have been 20 lines long, other people had solved it in two.  This is not to say that shorter solutions are always better, but it taught me to think about how to improve my programming.

One caveat: HackerRank solutions tend to be, well, hacks.  Not always the best way to code a good, maintainable solution.  But they do get you to think.

[Junilu Lacar]

I wrote:

Steve Keystone wrote:We've all heard of the Dummies series of how-to guides, well, I need something simpler.

Well, then you'd better get used to disappointment. Software development is complex and complicated because any non-trivial problem you try to solve with software is going to be complex and complicated. There's just no way around that.

Having said that, however, beginners have to start somewhere. My advice would be that once you have a good handle on the basic language constructs like if-then-else, for, while, etc., then start looking into things that make good programs good: design principles, proper assignment of responsibility, good abstractions, maintainability, clarity, extensibility, and other "-ity"s

For the junior programmers that I mentor, I emphasize clarity and maintainability. Related to that, I pound into their heads the need to always (that means almost every line of code that they write) look for opportunities to do one of these three refactorings:

1. Rename for clarity of intent.
2. Extract to eliminate duplication and/or move responsibility.
3. Compose method to get a single level of abstraction

I believe that if you try to find ways to do any or all three of these types of refactoring for every 5 to 10 lines of code that you write, you'll be in good shape in understanding what it takes to write good programs.

This to me would be the first step towards understanding what it takes to be a better programmer. Once you are comfortable with the above and get a hang of writing clear and expressive code, then you can cast your net farther and wider by delving into things like SOLID design principles, 4 Rules of Simple Design, and maybe even test-driven development. It might even serve you well to read ahead on those topics, even if they seem way over your head at first. Awareness of these kinds of considerations will still help you, IMO, even if you don't fully understand how they come into play or when to apply them.

If you've ever studied a martial art, the learning process is very similar. Beginners are often exposed to advanced techniques just so they can see that the basic things they are learning are just building blocks. As your study advances, those basic building blocks come together in a multitude of different ways and are assimilated and transformed into larger, more elaborate movements and techniques. And the thing that determines how these pieces come together in more advanced applications is context, of course. Every situation has its own set of forces and dynamics to which you have to adapt and use the tools and techniques at your disposal. The trick is knowing how, when, and to what degree you use those tools in a manner that is appropriate to the given situation you are facing.

*NOTE: those who know me around here are probably thinking "there it is, the MA + TDD mention "  Well, sorry, can't help going back to that analogy every time. It's been a big part of my own development as a programmer.

[Steve Keystone]

Knute, once again thanks for the help, I'l definitely look into HackerRank. I'm the type that learns by multiple examples.

Junilu, I appreciate you revisiting your post. I will take those suggestions on board and move forward.