OOP and the scope of a class, am I wrong?
-
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
ReadTextFile
and 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
Your description is very accurate IMHO... Can you - secretly - share the name of the places those professors teaching? I want to ensure my kids don't go near there... :-D
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
-
I believe ablative gerund belongs to latin grammar, and there is no such thing as easy latin. But I'm probably wrong though, as I never learned latin.
Wrong is evil and must be defeated. - Jeff Ello
Awesome rabbit-hole :)
-
Holy ... Dear Richard, you know me now for a longer time as an English non native. Can you please describe 'ablative gerund' in _very simple words_ for me? Thank you very much in advance ;)
-
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
ReadTextFile
and 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:
A car class might contain 4 Tire class instances ... Am I wrong here?
Yes - you misspelled "tyre". ;P
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
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.
-
Your description is very accurate IMHO... Can you - secretly - share the name of the places those professors teaching? I want to ensure my kids don't go near there... :-D
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
You're probably safe. I ran into this while helping a student from 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
-
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
ReadTextFile
and 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 like ReadTextFile
I hope what they meant (but probably didn't clearly convey) is a recommendation for a
TextFileReader
class (that derives fromFileReader
that derives fromStreamReader
) that has methods like Read() and ReadToEnd(). /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
honey the codewitch wrote:
professors are teaching that classes are effectively a single action like ReadTextFile
I hope what they meant (but probably didn't clearly convey) is a recommendation for a
TextFileReader
class (that derives fromFileReader
that derives fromStreamReader
) that has methods like Read() and ReadToEnd(). /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Not at all. It had ParsePatientData, and OuputPatientData Yeah. It's like that. And the assignment required the name.
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
ReadTextFile
and 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 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"...
-
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"...
That's almost certainly what is being taught. It comes from the (very helpful) book 'Design Patterns' by Erich, Gamma, et. al. (aka. 'the Gang of Four' ... abbreviated everywhere to 'GoF'). It is useful in particular situations, and it has trade-offs. Professors should teach it, but I doubt they are advocating that it should be always done that way ... that's more likely students not grasping the nuance of when to apply the pattern.
-
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
ReadTextFile
and 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
-
Of course, but I was simplifying and glossing over details to simply get to the larger point, to wit: In my mind, a class is a noun, not a verb, essentially.
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:
In my mind, a class is a noun, not a verb, essentially
For me, a class may be either a noun or a verb. As a noun, the concept represented by the class is a thing, and the class provides information and operations for that thing. For a verb the concept is a process, and the class supports that process. I guess 'process' can be thought of as a noun, but thinking of it that way adds indirection to my thinking.
Software Zen:
delete this;
-
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
ReadTextFile
and 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
No, you are correct. Your car is a valid class as you define it. ReadTextFile() is a function. To be a valid class, imo, it would be TextFile as the class, with properties and actions. TextFile.length, etc. and TextFile.Read,write,etc. My take, in English grammar, is that a class should be a noun, with adjectives, verbs and possibly adverbs that go with it. If it's short of that, it deserves another look for consideration as a function or structure. I suppose, depending on the language, a class could be looked at as a convenient way to store a reusable. What a declaration nightmare that creates, using your example.
-
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
ReadTextFile
and 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:
But I'm hearing that professors are teaching that classes are effectively a single action like ReadTextFile and it makes me a lot more irritated than I probably should be.
You're right. A class encapsulate a physical or logical object, including ways to interact with the object. What that professor is teaching is sheer idiocy. Many moons ago a friend relayed a story -- we worked for a consulting firm and he did the tech interview for a professor that had taught VB at the local community college for 5 years. She failed the interview and he recommended against hiring her. Why? She knew the syntax of the language better than he did, but she had NO idea how to actually program. She could answer questions such as "which method to use to add an item to a listbox" (something we didn't bother asking), but didn't know which construct to use for looping. She could write an if loop, but couldn't tell when to use if or while or foreach. He went into the interview assuming it was a formality, and ended up vetoing her. Far too many college professors have no real world experience.
-
He designed C++ not OOP
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
But he explained OOP that way and the implmentation in C++ was that way as well.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
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
ReadTextFile
and 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`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.
-
Personally I can't make a bridge between ReadTextFile and the car... Anyway you example shows a classic thing, that classes are usually not 'stand alone' and in a certain way 'connected'/'depended' Your examlpe: Engine.Start() does depend on the state of the Gear. Either Engine asks the gear for 'I'm ready to start' or the gear sends a message to the engine 'hey, I'm at gear 1 (without pressed clutch), not really good to start at the moment' and so on and on and on... Abstracting the reality is usually very hard. Only my two cents.
0x01AA wrote:
Abstracting the reality is usually very hard.
Abstracting reality may be difficult but its absolutely essential. If you see a chair that you've never seen before and you don't have an abstract concept of what a chair is, how would you ever know its a chair? It sounds like this professor had a difficult time with the abstract concept of a class. It can be a difficult concept but I would think it would be a prerequisite to being an IT professor. But what do I know? I'm self taught and assume there a plenty of abstract concepts I'm just not aware of.
-
Mixing (up) function(s) and actions. ReadTextFile is some clumsy rewording of a "TextReader" class.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
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
ReadTextFile
and 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
Sounds like someone misunderstood. Those will be some messed up students if they come out thinking classes are/should be SRP. Methods/functions sure, but... OOP tends to be highly overrated when you turn on the ultra pedant. Probably through here, I've read recent articles from others who spit on DRY and recognize that classic OOP has some serious faults.
-
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
ReadTextFile
and 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
Well, at least we'll never be unemployed!