|
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.
|
|
|
|
|
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...
|
|
|
|
|
This article was posted a few weeks ago on oct. 20, 2023
What a medievalist coding movement tells us about our modern digital world - SD Times[^]
It's a really odd article because:
1. I've never heard of this "movement" before.
2. It mentions...
Quote: The Software Craftsmanship movement thinks it is a trade closer to carpentry or blacksmithing. They mark their communities on maps with heraldry, publish books with covers featuring pictures of old tools, and discuss the “Scribe’s Oath” at conferences.
3. It also says, that thousands of devs have signed...but doesn't mention where this "digital parchment" exists -- no links in the article.
Quote: Tens of thousands of developers signed that piece of digital parchment because it meant something to them, just as the artists and craftspeople of the late 19th century flocked to Arts and Crafts.
I found the Manifesto For Software Craftsmanship[^] but it is quite old (though there are over 34,000 signees) -- you have go to this metrics link[^] to see how many have signed since 2009 or so.
Also, if you scroll down on the first link you'll see the signees and you can search. It's an odd site. Also, you can sign it too, if you want.
Have you ever heard of this before? I think the movement kind of died out really, and I can't figure out why this article was recently written (slow news day I guess).
The article mentions a few books that support these ideas:
Pragmatic Programmer, The: Your journey to mastery, 20th Anniversary Edition[^] which really is a great read.
Anyways, have you heard of this "movement" before? I've read the book above but never heard of this.
modified 6-Nov-23 11:25am.
|
|
|
|
|
As a Medievalist programmer, I use leeches to fix bugs.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
I believe that witches are the source of all bugs.
BURN THE WITCHES!
(Our own codewitch excepted)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
You call them witches we call them users 
veni bibi saltavi
|
|
|
|
|
Ah, bloodletting! THE classic debugging technique for over 3,000 years!
Now that's old school debugging.
|
|
|
|
|
Don't get me started about how breakpoints *really* got their name.
|
|
|
|
|
Dave Kreskowiak wrote: Now that's old school deinbugging.
FTFY 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
At one time, programming (well) was considered a craft. Then came the script kiddies.
"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
|
|
|
|
|
Gerry Schmitz wrote: Then came the script kiddies.
And VB6
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Gerry Schmitz wrote: programming (well)
Long ago and even now titles often accrue by longevity. Only sometimes does that reflect above average skill.
But idiots have always existed.
|
|
|
|
|
At one time, we discussed authors: Martin; Date; Codd; Yourdon; DeMarco; The Gang of Four; ... We're now left with "Musk" and his plagiarism of "grok" and "groking".
"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
|
|
|
|
|
Gerry Schmitz wrote: At one time, we discussed authors:
Yes but at that time we also did it while standing around the water cooler wearing our ties. Perhaps after just returning from the technical book store with a new book. Before returning to our individual offices.
Presuming of course that the discussion was not on a college campus.
Not to mention of course that the number of books back then for programming was perhaps an order of magnitude smaller. I would say at a certain point at time it was at least two orders smaller. So much easier to discuss the same book.
I will note that I am currently reading a O'Reilly Microservices book. I just checked Amazon there are about 35 books with 'Microservices' in the title. Eight of those are from O'Reilly.
For comparison O'Reilly did not start publishing books until about 1984 and Coad's first book was in 1990.
One just needs to accept that things move fast.
|
|
|
|
|
raddevus wrote: but it is quite old (though there are over 34,000 signees)
Googling suggests there are more than 27 million programmers.
Even presuming that all of those signers are in fact programmer I would still expect you can get more people to agree to and sign a petition about the best drink when programming.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
