82
Hmmm...yes this isn't C#....this isn't C# at all. I can't read this.
Hey now, you should be thanking your teachers for this incredibly valuable early life lesson on the difference between what the customer says that they want and what they actually need, and which of these two you are going to get paid more for!
Remember: the customer is always right!
/s
Most of my college coursework was around OOP. That said, they actually did a pretty lousy job of explaining it in a practical sense, so since we were left to figure it out ourselves a lot of our assignments ended up looking like this.
At the end of the program, our capstone project was to build a full stack app. They did a pretty good job simulating a real professional experience: we all worked together on requirements gathering and database design, then were expected to build our own app.
To really drive home the real world experience, the professor would change the requirements partway through the project. Which is a total dick move, but actually a good lesson on its own.
Anyway, this app was mostly about rendering a bunch of different views, and something subtly would change that ended up affecting all views. After the fact, the professor would say something to the effect of "If you used good objects, you'll only have to make the change in one place."
This of course is only helpful if you really appreciated the power of OOP and planned it from the start. Most of us were flying by the seat of our pants, so it was usually a ton of work to get those changes in
If you used good objects, you'll only have to make the change in one place
IMO that's generally a retroactive statement because in practice have to be lucky for that to be true. An abstraction along one dimension -- even a good one, will limit flexibility in some other dimension.
Occasionally, everything comes into alignment and an opportunity appears to reliably-ish predict the correct abstraction the future will need.
Most every other time, you're better off avoiding the possibility of the really costly bad abstraction by resisting the urge to abstract preemptively.
Same, I always remember this with interfaces and inheritance, shoehorned in BS where I'm only using 1 class anyway and talking to 1 other class what's the point of this?
After I graduated as a personal project i made a wiki for a game and I was reusing a lot of code, "huh a parent class would be nice here".
In my first Job, I don't know who's going to use this thing I'm building but these are the rules: proceeds to implement an interface.
When I have to teach these concepts to juniors now, this is how I teach them: inheritance to avoid code duplication, interfaces to tell other people what they need to implement in order to use your stuff.
I wonder why I wasn't taught it that way. I remember looking at my projects that used this stuff thinking it was just messy rubbish. More importantly, I graduated not understanding this stuff...
I wouldn't say that inheritance is for avoiding code duplication. It should be used to express "is a" relationship. An example seen in one of my projects: a mixin with error-handling code for a REST service client used for more than one service has log messages tightly coupled to a particular service. That's exactly because someone thought it was ok to reuse.
In my opinion, inheritance makes sense when you can follow Liskov's principle. Otherwise you should be careful.
You're not wrong but I think when you're teaching someone just having 1 parent and 1 child class makes for a bad example I generally prefer to use something with a lot of different children.
My go-to is exporters. We have the exporter interface, the generic exporter, the accounting exporter and the payroll exporter, to explain it.
At school, the only time I used inheritance was 1 parent (booking) and 1 child (luxury) this is a terrible example imo.
Maybe that example was made terrible because the author couldn't think of a good ways to show how great this can be. I'm obviously a fan of SOLID, and OCP is exactly why I don't worry if I have only one class at the beginning. Because I know eventually requirements would change and I'd end up with more classes.
Some time ago I was asked by a less experienced coworker during a code review why I wrote a particularly complex piece of code instead just having a bunch of if statements. Eventually this piece got extended to do several other things, but because it was structured well, extending it was easy with minimum impact for the code-base. This is why design matters.
Above claims are based on nearly 2 decades of writing software, 3/4 of it in big companies with very complex requirements.
inheritance to avoid code duplication
What no, inheritance is not for code sharing
Sound bite aside, inheritance is a higher level concept. That it "shares code" is one of several effects.
The simple, plain, decoupled way to share code is the humble function call, i.e. static method in certain langs.
This is Java, so you can even turn those ints into Integers and doubles into Doubles if you want to maximize the objects in that part of the code. In all seriousness, though, it looks perfectly fine to me.
Great idea, but unfortunately technicalities won't get me marks.
but Strings are objects ๐
But answer07 is an object... Not sure what your teacher/ta disliked ๐
I presume WeatherData.getData() should be going into some Data class that has multiple properties (using the , as a delimiter) instead of what OP is doing and just using the String
I mean, unless it's explicitly specified, one can still argue. For fun, that is. I did it a few times with stuff like using maps when the task said I couldn't use loops. Didn't really get into trouble since there was a proper solution ready as well.
This is one condition in which I might like the "If it runs, you get marks" examiners
To be needlessly pedantic on this joke, answer07 in itself is not an object, but a class, a blueprint for objects. An instance of that class would be an object. Calling the static function main does also not create an instance of the class in the class loader.
To expand on that you can never instantiate an object of type answer07 since it's a static class.
(For the students here the "static" modifier means "it's on the class, not the object". Non-static will only be accessible as a "obj.whatever" but static is accessible by "Class.whatever")
Is the class declared static? I assume the "...ic class Answer07" at the top stands for "public class Answer07".
I don't think java supports top level static classes (it does have nested static classes, though).
Oh, I haven't handed it in yet. We were supposed to write our own methods.
So really it's in a few days iwfu(I will fuck up)
TIFU by using eclipse
this post was submitted on 14 Nov 2024
82 points (95.6% liked)
Programmer Humor
19551 readers
494 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS