|
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.
|
|
|
|
|
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.
|
|
|
|
|
Many people consider this a must read for OOP/class deisgn -
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
#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
|
|
|
|
|
|
Well, at least we'll never be unemployed!
|
|
|
|
|
You are right - someone will have to come along afterwards and clean this all up... 
|
|
|
|
|
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.
|
|
|
|
|
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 only reasonable thing I think the professor could have referred to is what Gerry Schmitz above (~3rd from top) referred to
class TextReader which 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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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. 
Will Rogers never met me.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
