I love OO, but man, you can over due it really easily. Still sweet and my favorite way to code though.
Yeh. Learning how to write plain C in an OO manner was one of the more interesting things I've learned at this school. It gave me new respect for having language support for classes, or even something like Go that isn't fully OO (no inheritance), but at least has interfaces and lets you assign functions to types (basically methods, so any type that has the right methods fits a given interface, and "interface{}" fits all types).
Java is just a very verbose way of expressing OO. C# cleans it up quite a lot but I feel sometimes it should have been a bit more daring with the syntax.
Monkey Ball Warrior on
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
I remember my lecture on OO programming on C. My first thought was “maybe leave the Object Oriented programming to the Object Oriented languages”. Taking the slight performance hit is worth it to get proper support for the paradigm.
When people unite together, they become stronger than the sum of their parts.
Don't assume bad intentions over neglect and misunderstanding.
I think one of my favorite quotes I've seen about OO recently was from one of the more well known Scala devs on twitter (I forget which one). It was basically "Sure, OO is very powerful. It's just that it's the sort of power only wielded by madmen and evil sorcerers." Referring to it being very flexible and powerful, but very easy to overdo and make a convoluted mess with all of that flexibility combined with mutability.
I love OO for code organization, but I totally understand the issue. I'm always fighting with myself on how much flexibility I need... do I need a parent class and then subclasses because feature X might happen in the future or do I keep it simple and just create this one class, etc.
I try to tame my OO designs with KISS and YAGNI. Success varies, though. Sometimes it is the right call to add a bit of complexity now in the interest of simplifying the future, as long as that future isn't too distant.
I think one of my favorite quotes I've seen about OO recently was from one of the more well known Scala devs on twitter (I forget which one). It was basically "Sure, OO is very powerful. It's just that it's the sort of power only wielded by madmen and evil sorcerers." Referring to it being very flexible and powerful, but very easy to overdo and make a convoluted mess with all of that flexibility combined with mutability.
I love OO for code organization, but I totally understand the issue. I'm always fighting with myself on how much flexibility I need... do I need a parent class and then subclasses because feature X might happen in the future or do I keep it simple and just create this one class, etc.
Exactly. Sometimes you just have to take a step back and go WHOA WHOA WHOA!!! I will NEVER reuse this code, I'm going to make a Duck() class instead of an OxygenBreather->Animal->WingedAnimal implements LivesInWater-> Duck() class.
The point of OO isn't that you need to implement or account for everything.
The most powerful aspect of OO is that if you're doing it right, you'll be able to adapt and implement things when you need them without having to throw up your hands and start over.
The point of OO isn't that you need to implement or account for everything.
The most powerful aspect of OO is that if you're doing it right, you'll be able to adapt and implement things when you need them without having to throw up your hands and start over.
I think that's why I like it. Its very easy to change direction midway through and still have very readable code. But doing it "right" and designing it with full OO in mind and such just makes me insane. Like my aforementioned OxygenBreather example.
Yeah adding fields to a class isn't a thing, but the point is one day down the line when you want to change MyClass->Action(); to work with a different internal method, the person on the outside won't notice it.
So maybe you found a better way to sort your list, the person on the outside doesn't need to care. That's the largest benefit to OOD. There are more but that's the way I see it.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Yeah adding fields to a class isn't a thing, but the point is one day down the line when you want to change MyClass->Action(); to work with a different internal method, the person on the outside won't notice it.
So maybe you found a better way to sort your list, the person on the outside doesn't need to care. That's the largest benefit to OOD. There are more but that's the way I see it.
That is more about contract interface than OO, but for good reasons it is associated with class interfaces.
Plugging my webgame of sorts here since the theme probably appeals to some.
Was a game/interface I made as part of a Phalla game on the boards here last year and I'm going to update it into something that will just stand on its own.
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
The thing about people who rally against OO because it's "powerful and you can hurt yourself with it" tend to be academic types who haven't actually written real software in their entire life. Yes, you can write shit code with it. I can write shit functional code with Lisp too. And I can write shit procedural code with C. Over years of experience doing OO, you learn how to avoid writing that shit code. You learn when you're "overdoing it" (we call this over engineering, it has a real term). You learn to sniff out very quickly when you've architected a system to be too complex or not complex enough.
Yeah adding fields to a class isn't a thing, but the point is one day down the line when you want to change MyClass->Action(); to work with a different internal method, the person on the outside won't notice it.
So maybe you found a better way to sort your list, the person on the outside doesn't need to care. That's the largest benefit to OOD. There are more but that's the way I see it.
That is more about contract interface than OO, but for good reasons it is associated with class interfaces.
Completely ignoring contract interface, it's also an example of encapsulation and separation of concerns, both huge pillars of OO. You can do what Bowen is describing without any sort of contractual interface, though providing one makes the design cleaner and easier to predict.
The thing about people who rally against OO because it's "powerful and you can hurt yourself with it" tend to be academic types who haven't actually written real software in their entire life. Yes, you can write shit code with it. I can write shit functional code with Lisp too. And I can write shit procedural code with C. Over years of experience doing OO, you learn how to avoid writing that shit code. You learn when you're "overdoing it" (we call this over engineering, it has a real term). You learn to sniff out very quickly when you've architected a system to be too complex or not complex enough.
And unfortunately it isn't something you can teach. It is just experience.
Yeah adding fields to a class isn't a thing, but the point is one day down the line when you want to change MyClass->Action(); to work with a different internal method, the person on the outside won't notice it.
So maybe you found a better way to sort your list, the person on the outside doesn't need to care. That's the largest benefit to OOD. There are more but that's the way I see it.
That is more about contract interface than OO, but for good reasons it is associated with class interfaces.
Completely ignoring contract interface, it's also an example of encapsulation and separation of concerns, both huge pillars of OO. You can do what Bowen is describing without any sort of contractual interface, though providing one makes the design cleaner and easier to predict.
There may be more formal lines drawn but to me contract interface means/includes "I am giving you this and expect this, sort it out however you like." So it means those other things too imo.
As I said, all common themes in OO, but not things that require OO.
The thing about people who rally against OO because it's "powerful and you can hurt yourself with it" tend to be academic types who haven't actually written real software in their entire life. Yes, you can write shit code with it. I can write shit functional code with Lisp too. And I can write shit procedural code with C. Over years of experience doing OO, you learn how to avoid writing that shit code. You learn when you're "overdoing it" (we call this over engineering, it has a real term). You learn to sniff out very quickly when you've architected a system to be too complex or not complex enough.
And unfortunately it isn't something you can teach. It is just experience.
So keep on keeping on~
Premature polymorphism is a lot like premature optimization, in my experience.
New kid at work. He's an intern working on my project. He's about 3 weeks away from graduating... And hasn't heard of regex before.
It was 4 years after I graduated before I heard of regex.
But I graduated ten years ago from a crappy school. (My assembly class was for some IBM-specific hardware that required us to use an emulator and photocopied book because it went out of print a decade before).
Java is an example of when you under do it but don't provide any other way. The decision to not make functions first class objects is still inexplicable to this day.
Yeah adding fields to a class isn't a thing, but the point is one day down the line when you want to change MyClass->Action(); to work with a different internal method, the person on the outside won't notice it.
So maybe you found a better way to sort your list, the person on the outside doesn't need to care. That's the largest benefit to OOD. There are more but that's the way I see it.
That is more about contract interface than OO, but for good reasons it is associated with class interfaces.
Completely ignoring contract interface, it's also an example of encapsulation and separation of concerns, both huge pillars of OO. You can do what Bowen is describing without any sort of contractual interface, though providing one makes the design cleaner and easier to predict.
There may be more formal lines drawn but to me contract interface means/includes "I am giving you this and expect this, sort it out however you like." So it means those other things too imo.
As I said, all common themes in OO, but not things that require OO.
I think I'd call it "black boxing", but I'd probably be misusing the term.
Java is an example of when you under do it but don't provide any other way. The decision to not make functions first class objects is still inexplicable to this day.
Maybe they didn't want to deal with closures? (Depending on what you consider first class object to mean)
The thing about people who rally against OO because it's "powerful and you can hurt yourself with it" tend to be academic types who haven't actually written real software in their entire life. Yes, you can write shit code with it. I can write shit functional code with Lisp too. And I can write shit procedural code with C. Over years of experience doing OO, you learn how to avoid writing that shit code. You learn when you're "overdoing it" (we call this over engineering, it has a real term). You learn to sniff out very quickly when you've architected a system to be too complex or not complex enough.
The reason that academics (in particular certain PL folk) don't like OO is because it precisely leads to overly complex code whereas functional styles lead to more concise, elegant code.
There's a whole bunch of features mixed into the debate when it is phrased as "OO vs. functional" (like mutation, ADTs, polymorphism, etc.) so its not a cut-and-dry argument. However, after being in industry and academia now, I'm firmly in the functional side of things.
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
To be honest, I don't know regex. I dealt with it about 1 class before graduation and I said "what the fuck is this fucking shit?" and then stopped dealing with it. I mean I can do it, but it takes me like 12 times as long to do it the regex way as it does to actually take the verbiage, break it down, and check for correctness via tokens.
something@domain.com is really easy to check tokenwise. You do the same thing properly in regex and you're looking at, easily, a 256+ character regex that makes 0 sense outside of people that specialize in regex or have hours to dissect it.
Regex causes way more problems than it's worth. I'd probably admit to not knowing it too if someone asked me or if an interviewer questioned why I don't use it.
I wouldn't want to work for someone that uses regex anyways, shit be poopybutt-like.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
The thing about people who rally against OO because it's "powerful and you can hurt yourself with it" tend to be academic types who haven't actually written real software in their entire life. Yes, you can write shit code with it. I can write shit functional code with Lisp too. And I can write shit procedural code with C. Over years of experience doing OO, you learn how to avoid writing that shit code. You learn when you're "overdoing it" (we call this over engineering, it has a real term). You learn to sniff out very quickly when you've architected a system to be too complex or not complex enough.
The reason that academics (in particular certain PL folk) don't like OO is because it precisely leads to overly complex code whereas functional styles lead to more concise, elegant code.
There's a whole bunch of features mixed into the debate when it is phrased as "OO vs. functional" (like mutation, ADTs, polymorphism, etc.) so its not a cut-and-dry argument. However, after being in industry and academia now, I'm firmly in the functional side of things.
And even if you are just taking some aspect of functional and using them in a basically OO system it is still a nice way to make things clear and clean. Or at least it feels that way, I'm far too new at coding to be good at design yet.
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
I thought I went to a shitty school, and we still had a class on finite automata and regular grammers. We covered the formal definition of turing machines, and pumping lemma and than had to build basic regular grammers and DFA's for a simple regular expression parser.
Ethea on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
The thing about people who rally against OO because it's "powerful and you can hurt yourself with it" tend to be academic types who haven't actually written real software in their entire life. Yes, you can write shit code with it. I can write shit functional code with Lisp too. And I can write shit procedural code with C. Over years of experience doing OO, you learn how to avoid writing that shit code. You learn when you're "overdoing it" (we call this over engineering, it has a real term). You learn to sniff out very quickly when you've architected a system to be too complex or not complex enough.
The reason that academics (in particular certain PL folk) don't like OO is because it precisely leads to overly complex code whereas functional styles lead to more concise, elegant code.
There's a whole bunch of features mixed into the debate when it is phrased as "OO vs. functional" (like mutation, ADTs, polymorphism, etc.) so its not a cut-and-dry argument. However, after being in industry and academia now, I'm firmly in the functional side of things.
I'm on the "correct tool for the job" side of things. In most cases, that ends up being a mixture of OO and functional design patterns. They actually mix incredibly well if you know what you're doing.
The problem is too many people graduate from college and think they know what they are doing: They don't. It takes college + years of experience to actually know what you're doing, and the part that is optional is the college, not the years of experience. Not that college is bad, I recommend it for everyone. People just need to understand what a comp sci program is actually going to give you, and what it's not going to give you.
If the order of the list means something top your application.
If you need to define a view or slice of the group a list will be easier
If you can use a custom allocator for the list it can get great sequential iteration performance ( but just use a vector )
list can be used by multiple threads where one removes items and another adds items way easier than a hash map
I expect rehasing will be slow, so if you are dramatically changing the amount of items being stored a list would preform better.
Posts
:rotate:
Yeh. Learning how to write plain C in an OO manner was one of the more interesting things I've learned at this school. It gave me new respect for having language support for classes, or even something like Go that isn't fully OO (no inheritance), but at least has interfaces and lets you assign functions to types (basically methods, so any type that has the right methods fits a given interface, and "interface{}" fits all types).
Java is just a very verbose way of expressing OO. C# cleans it up quite a lot but I feel sometimes it should have been a bit more daring with the syntax.
Don't assume bad intentions over neglect and misunderstanding.
I love OO for code organization, but I totally understand the issue. I'm always fighting with myself on how much flexibility I need... do I need a parent class and then subclasses because feature X might happen in the future or do I keep it simple and just create this one class, etc.
Exactly. Sometimes you just have to take a step back and go WHOA WHOA WHOA!!! I will NEVER reuse this code, I'm going to make a Duck() class instead of an OxygenBreather->Animal->WingedAnimal implements LivesInWater-> Duck() class.
The most powerful aspect of OO is that if you're doing it right, you'll be able to adapt and implement things when you need them without having to throw up your hands and start over.
I think that's why I like it. Its very easy to change direction midway through and still have very readable code. But doing it "right" and designing it with full OO in mind and such just makes me insane. Like my aforementioned OxygenBreather example.
YOU SHALL NOT DERIVE
So maybe you found a better way to sort your list, the person on the outside doesn't need to care. That's the largest benefit to OOD. There are more but that's the way I see it.
That is more about contract interface than OO, but for good reasons it is associated with class interfaces.
Uh.. finder's fee and all.
Was a game/interface I made as part of a Phalla game on the boards here last year and I'm going to update it into something that will just stand on its own.
Completely ignoring contract interface, it's also an example of encapsulation and separation of concerns, both huge pillars of OO. You can do what Bowen is describing without any sort of contractual interface, though providing one makes the design cleaner and easier to predict.
And unfortunately it isn't something you can teach. It is just experience.
So keep on keeping on~
There may be more formal lines drawn but to me contract interface means/includes "I am giving you this and expect this, sort it out however you like." So it means those other things too imo.
As I said, all common themes in OO, but not things that require OO.
Premature polymorphism is a lot like premature optimization, in my experience.
I wrap them both under the header of over-engineering.
Does he know Java?
It was 4 years after I graduated before I heard of regex.
But I graduated ten years ago from a crappy school. (My assembly class was for some IBM-specific hardware that required us to use an emulator and photocopied book because it went out of print a decade before).
A good thing in my book.
Java is an example of when you under do it but don't provide any other way. The decision to not make functions first class objects is still inexplicable to this day.
I made a game, it has penguins in it. It's pay what you like on Gumroad.
Currently Ebaying Nothing at all but I might do in the future.
Does he not know regular expressions or the function regex? Because it'd be odd to graduate without learning the former.
Don't assume bad intentions over neglect and misunderstanding.
Maybe they didn't want to deal with closures? (Depending on what you consider first class object to mean)
The reason that academics (in particular certain PL folk) don't like OO is because it precisely leads to overly complex code whereas functional styles lead to more concise, elegant code.
There's a whole bunch of features mixed into the debate when it is phrased as "OO vs. functional" (like mutation, ADTs, polymorphism, etc.) so its not a cut-and-dry argument. However, after being in industry and academia now, I'm firmly in the functional side of things.
something@domain.com is really easy to check tokenwise. You do the same thing properly in regex and you're looking at, easily, a 256+ character regex that makes 0 sense outside of people that specialize in regex or have hours to dissect it.
Regex causes way more problems than it's worth. I'd probably admit to not knowing it too if someone asked me or if an interviewer questioned why I don't use it.
I wouldn't want to work for someone that uses regex anyways, shit be poopybutt-like.
And even if you are just taking some aspect of functional and using them in a basically OO system it is still a nice way to make things clear and clean. Or at least it feels that way, I'm far too new at coding to be good at design yet.
I'm on the "correct tool for the job" side of things. In most cases, that ends up being a mixture of OO and functional design patterns. They actually mix incredibly well if you know what you're doing.
The problem is too many people graduate from college and think they know what they are doing: They don't. It takes college + years of experience to actually know what you're doing, and the part that is optional is the college, not the years of experience. Not that college is bad, I recommend it for everyone. People just need to understand what a comp sci program is actually going to give you, and what it's not going to give you.
Normally I'd flip around your assumption though: you wouldn't care about using a hashmap unless you need to look something up via some identifier.
if you need an ordered hashmap, it looks like LinkedHashMap does what you want
If you need to define a view or slice of the group a list will be easier
If you can use a custom allocator for the list it can get great sequential iteration performance ( but just use a vector )
list can be used by multiple threads where one removes items and another adds items way easier than a hash map
I expect rehasing will be slow, so if you are dramatically changing the amount of items being stored a list would preform better.