OOP and the scope of a class, am I wrong?
-
#AdmiralAckbar It's a trap! Hopefully... he's gonna angle that into ok, that was a good start, but... sorta thing.
I explained that while he should do as the assignment requires, a class encapsulates related data and actions, so it really was an inappropriate name for a class. I suggested another name "PatientDataReader" or something (I forget exactly, but it was better) if he was doing it on his own.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
My take: A class should group related data and actions that center around a single concept. A car class might contain 4 Tire class instances as data members, an Engine instance, and a Gearbox instance. Each one has actions relevant to its operation like Engine.Start(), and Wheel.Rotate() But I'm hearing that professors are teaching that classes are effectively a single action like
ReadTextFileand it makes me a lot more irritated than I probably should be. Am I wrong here?Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
You are right. A class should represent some definable entity, whether atomically (e.g. Tire class) or in the aggregate of related entities (Car class that inherits Vehicle class, containing a Tire class collection, Engine class, Transmission class, etc.). Whatever "professors" that are saying what you report need to go get their hands dirty writing and supporting production software to test their theories before opening their mouths to sound foolish.
-
Well, at least we'll never be unemployed!
You are right - someone will have to come along afterwards and clean this all up... :doh:
-
My take: A class should group related data and actions that center around a single concept. A car class might contain 4 Tire class instances as data members, an Engine instance, and a Gearbox instance. Each one has actions relevant to its operation like Engine.Start(), and Wheel.Rotate() But I'm hearing that professors are teaching that classes are effectively a single action like
ReadTextFileand it makes me a lot more irritated than I probably should be. Am I wrong here?Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
professors are teaching that classes are effectively a single action
That sounds like a method, not a class. Or a class with one method, which smells funny. Factoring OO is something that's taught in school, but not really understood until you get experience with it. Judgment calls have to be made. I've had to work with OO code that broke everything down into atomic classes. It was a nightmare to trace the code, and imagine what that does to the stack.
-
honey the codewitch wrote:
professors are teaching that classes are effectively a single action
That sounds like a method, not a class. Or a class with one method, which smells funny. Factoring OO is something that's taught in school, but not really understood until you get experience with it. Judgment calls have to be made. I've had to work with OO code that broke everything down into atomic classes. It was a nightmare to trace the code, and imagine what that does to the stack.
StatementTerminator wrote:
I've had to work with OO code that broke everything down into atomic classes.
To me that seems quite common these days in enterprise apps, almost as though someone made it by creating one extremely detailed UML diagram and then generating code from that. I've even seen many projects posted here that seem to overly factor. It does make it a nightmare to trace. I usually can't make much sense of code that's overly factored.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Ha ha! I remember "ablative" and "gerund" from my Latin classes back in the 1950s. So I just put the two words together as a joke. But the joke, it appears, is on me, as there realy is such a thing. But I am not sure exactly what that thing is.
-
[Gerund and Gerundive | Dickinson College Commentaries](https://dcc.dickinson.edu/grammar/latin/gerund-and-gerundive#:~:text=The ablative of the gerund,%2C and (rarely) prō.)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
That's a good point. I was trying to get to the essence of it and simplify, but obviously I missed the mark in terms of covering every eventuality.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Keeping in mind of course that a school class is intended to teach concepts not practice. So in general one can think of it as a noun but if someone insists that every single class must always follow some rule about that then it is going to be a problem.
-
Yeah plural, as I've seen before in other assignments in the past. CS coursework, last one at a uni in south africa.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I guess that could be considered a class in a command-based architecture, where ReadTextFile inherits from (or implements) some sort of base Command class and it contains all the information the processing system needs to perform that action, but it's a stretch, and certainly not to be taught as "the norm"...
Mark Quennell wrote:
where ReadTextFile inherits from (or implements) some sort of base Command class
Interesting possibility. Although then either the class should be an advanced one or specifically about patterns. Patterns should not be introduced in an introductory course.
-
I`d say no you are not wrong, but the teacher is not necessarily wrong either. A class can be almost anything in C++. - Can be an interface - Can be a functor - Can be just data - Whatever... so, depending on how the teacher wants the thing to evolve he might direct his students. with very little or no context it is hard to decide who's right. If you are using class to model things, they can be names. If they model actions, they can be verbs. If they model attributes, they can be adjectives. classes are one of the mechanisms for encapsulation & data hiding after that, when I do code review, I usually check the coupling between the class and the client, this usually tells me if the data hiding or encapsulation is at a proper level or done right.
Daniel Anderson 2021 wrote:
but the teacher is not necessarily wrong either
The teacher is wrong if the class is supposed to be an introduction of some sort. Especially if one is attempting to explain 'class' and 'methods'. One should not introduce advanced concepts until students have at least had the chance to master basics.
-
The directive in the assignment, which I had a copy of said literally name the class ReadTextFile.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
So then hypothetically and because you said elsewhere that it was copied... See the following. https://www.chegg.com/homework-help/questions-and-answers/using-java-programming-techniques-presented-fig-156-readtextfilejava-chapter-15-presentati-q57099852[^] In that there is nothing wrong with the 'class' being defined that way. Because it is main class in java. It is not a OO class but rather a specific type of java class. There appear to be other examples. I used the following to google.
programming assignment "class ReadTextFile"
-
My take: A class should group related data and actions that center around a single concept. A car class might contain 4 Tire class instances as data members, an Engine instance, and a Gearbox instance. Each one has actions relevant to its operation like Engine.Start(), and Wheel.Rotate() But I'm hearing that professors are teaching that classes are effectively a single action like
ReadTextFileand it makes me a lot more irritated than I probably should be. Am I wrong here?Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I would say that you are 100% correct. The weirdness started when languages and frameworks started making unreasonable demands of the analogy. Take, for instance, Java's everything is a class, even when it's not.. or the concept of microservices, where essentially every method is wrapped in a class because it is a self-contained unit. I think the weirdness stems from these scenarios and pollutes design spaces where it shouldn't.
-
It was an assignment, I think photocopied out of a book but I didn't ask.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
It was an assignment, I think photocopied out of a book
So, that means the Professor is just a willing purveyor of tripe who does not take the time to determine if the materials she uses have any value. Also, it means that the Professor is not the root cause of the problem -- just the purveyor. Which, in turn means... We need to get that book and destroy it. :laugh: I'd love to know the title of the book which has : 1. bamboozled the professor 2. is chosen by universities 3. is spreading lies about OOP :rolleyes:
-
honey the codewitch wrote:
It was an assignment, I think photocopied out of a book
So, that means the Professor is just a willing purveyor of tripe who does not take the time to determine if the materials she uses have any value. Also, it means that the Professor is not the root cause of the problem -- just the purveyor. Which, in turn means... We need to get that book and destroy it. :laugh: I'd love to know the title of the book which has : 1. bamboozled the professor 2. is chosen by universities 3. is spreading lies about OOP :rolleyes:
Keep in mind, I don't know for sure. I saw a snapshot of a printed assignment, or maybe it was a book. Like I said, I didn't ask. Jschell did some googling and found that other people made a class with that name. I'm pretty sure the prof adapted the assignment somewhat for his class though, for reasons.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
My take: A class should group related data and actions that center around a single concept. A car class might contain 4 Tire class instances as data members, an Engine instance, and a Gearbox instance. Each one has actions relevant to its operation like Engine.Start(), and Wheel.Rotate() But I'm hearing that professors are teaching that classes are effectively a single action like
ReadTextFileand it makes me a lot more irritated than I probably should be. Am I wrong here?Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Last time I was a paid programmer the concept of OOP was brand shiny new; they never mentioned it in school. The first I heard of it was in a night class at TRW on Ada, the DoD's latest answer to everything data. It was fascinating but extremely difficult to get a grip on the concepts, since most of us cut our teeth on FORTRAN and COBOL. My training and experience using it (I was in heaven when Turbo Pascal 5.5 introduced OOP to that perfect language) matches your understanding exactly. Over the years I've heard people redefining it, but I think you've nailed it. I still remember the first satisfying moment when I realized that a Class defined an Object, and objects were created by instantiating the Class. That's a hard one for an old (probably 30 yo by then) procedural programmer. :laugh:
Will Rogers never met me.
-
My take: A class should group related data and actions that center around a single concept. A car class might contain 4 Tire class instances as data members, an Engine instance, and a Gearbox instance. Each one has actions relevant to its operation like Engine.Start(), and Wheel.Rotate() But I'm hearing that professors are teaching that classes are effectively a single action like
ReadTextFileand it makes me a lot more irritated than I probably should be. Am I wrong here?Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Reading through all the responses just confirms to me that today nobody really understands anymore what OOP was supposed to be. And yes, the basic concept of OOP doesn't have a single "inventor", most certainly not Stroustrup, he is rather guilty of obfuscating the whole thing. People that had influence on the initial development of the OOP concept would rather be Alan Kay, Edsger Dykstra and Nikolaus Wirth. As for the scope of a class, it is quite difficult to give a quick example, but for the way I learned OOP, you professor would be wrong. Code abstraction is certainly one of the initial intends of OOP, but one of the fallacies that some people are going overboard with the level of abstraction. A single method and/or properties is just leading to obfuscation of the overall code, specially if that resulting class is used only in a single instance. Code abstraction is intended to help with the safely being able to reuse code and ease maintenance. Abstracting too much and you are just ending up in inheritance hell. That different implementations in different programming languages have different approaches to this is what makes OOP as it is often implemented today such a PITA...