OOP and the scope of a class, am I wrong?
-
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
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
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
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
Well, at least we'll never be unemployed!
-
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
Why does it have to be one or the other? One class could model a physical object like a car while another could model an operation such as a database transaction, file operation, or something more complex. At the end of the day it is about using the tools to minimize the cost of solving problems. And concepts like encapsulation and polymorphism frequently are the best tools for the job.
-
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
To a large extent the 'normalization' of classes is akin to the normalization of data records. The atomic characteristics of a class, that would drive application decomposition (and vice versa), can vary between applications. Thus a useful class decomposition in one instance can be a dogs breakfast in another. There is a similar problem when looking at communications protocols - doctrine dictates multiple layers but these can severely impede and bloat small systems. As humans show every moment, it is possible to communicate without layers (with varying degrees of success), particularly when context is available. For humans effective communication is possible even when the context is ambiguous. For myself, I have classes that do the equivalent of 'ReadTextFile' or 'ReadComPort' - these typically act as base class for different types of parser such that the data is transformed in some way into an easily digestible form for another part of the app. Whereas one may aspire to a 'universal' set of pattern classes, their utility will generally boil down to adaptation within specific application constraints.
-
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.
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
-
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;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
-
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 always split my OOP classes into two parts; classes for actions, and structures\structs for data. I just find it easier that way. I also try to limit what each would hold in the attempt to keep my classes\structures small. In the end, OOP's big advantage is its organizational capabilities within an application. And that organization is primarily up to the developer, not a professor...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
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
-
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
The only reasonable thing I think the professor could have referred to is what Gerry Schmitz above (~3rd from top) referred to
class TextReaderwhich is not insane in the terms of GOF (Design Patterns) but Prof's way of describing it is ofc misleading. e.g.class PngReader : public ImageReader {...
class SvgReader : public ImageReader { ...
"If we don't change direction, we'll end up where we're going"
-
The only reasonable thing I think the professor could have referred to is what Gerry Schmitz above (~3rd from top) referred to
class TextReaderwhich is not insane in the terms of GOF (Design Patterns) but Prof's way of describing it is ofc misleading. e.g.class PngReader : public ImageReader {...
class SvgReader : public ImageReader { ...
"If we don't change direction, we'll end up where we're going"
Yeah, and this could have also been CsvReader except it only read a specific CSV with certain columns and datatypes. ReadTextFile is maybe the worst name I could think of for that. =) PatientDataReader would have been better.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
#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.