@RobertHarvey Not related to what we were talking about earlier, but adding to the other two articles I linked before you might be interested in this. I only read the first couple articles in the list, but they seem to bring up some new things that I haven't read elsewhere.
I guess the other two people making the same suggestion are wrong too, then. If you aren't open to advice, then why did you ask the question? — Robert Harvey2 mins ago
@glennjackman Actually, SO is not an IT help desk. Fixing found code for non-programmers is too broad and therefore off-topic for this site. — TigerhawkT311 secs ago
@RobertHarvey Yeah, personally I'm still on the fence with OOP, I mostly use articles like these to look for ideas to make sure I'm getting a complete picture of what programmers find easy to read and use. They're not always super useful but sometimes they have one or two good insights I can consider.
Going off on a bit of a tangent, the research is wearing me out, I do it mostly on my own time (along with everything else going on). I'm pretty sure I'm the only one where I work that really cares about whether OOP is being used or not, or what it really means; the benefits have been... debatable at best, so I can't really sell the idea to management. 6 years in on and off and I'm still operating under "I think it's good in theory but I must not be doing it right.".
It adds insult to injury when testing shows that assembly language programs and procedural programs can easier to maintain, quicker to change, easier to delete, and more robust. I'd like to believe an OOP design can surpass that but when electricians can read the code in a procedural program and even skilled (admittedly with a possible procedural bias) programmers have trouble with OOP classes that seem to follow every rule I know of, well... it's confusing...
If that's too close to a rant I apologize, it's been a long day.
@jrh Honestly, I don't pay too much attention to it. I like OO, but I probably don't use it to it's extreme potential, and I certainly don't play Architecture Astronaut games with it. I'm quite comfortable making little widgets out of objects and classes, but I'm equally comfortable doing Functional and Procedural programming.
So I guess I just don't see what all the fuss is about. I'm very pragmatic; I do what works, and avoid orthodoxy and religions. I find people who barely know Java arguing about SRP and LSV amusing.
Reading blogs I see pragmatic programmers that take a hard line stance, which strikes me as a little odd. For me I just wish people would stop using single letter variable names for everything, if even that happened within my lifetime I'd consider that a huge thing. But even something that seems so obvious, it still hasn't propagated that far, I still open code and find alphabet soup, 12 years after Clean Code.
er, 8 years I mean. I was mixing it up with Code Complete's publish date.
@RobertHarvey By convention of bloggers, you're right, but the theory behind it seems to be mostly just rooted in (IMO) the most idealistic of OOP principles, it implies that everything will need to be overridden, and everything will need to have additional behavior later on; if I left a bunch of function pointers in a C struct, a programmer would naturally assume that at some point they would be set to something other than a static function...
... but what I don't understand is, why reduce the expressiveness of a language and lose the ability to say "this field has no reason to ever be anything other than data, should never be overridden, and you can just put data here without any worry if it failing" in a statically typed language, in smalltalk I agree a field makes no sense, but in C# I have a hard time understanding why this is such a big deal
@JayGould I am sorry, but this is all my Code and I think Git hub is a better place to show it... I just need a way so I can Somehow communicate with Motion.ai , through C# Software... — Raja Bilal55 secs ago
After reading Object Thinking I feel like the "Objects are things you send messages to, to interact with like physical objects" ship has long since sailed in C#, if anything VB.NET is closer because you can do Option Strict Off (if you really wanted to), though people seem to not recommend that (note: I don't recommend it either)
When you have to know (if not completely, partially) the type of everything, and primitive types exist and get passed by value (which has its advantages for sure), and it's not recommended (for good reasons, IMO) to do late binding on an Object (i.e., run some method MyMethod on Object and hope for the best) honestly, I feel like I ran out of real reasons to abandon internal fields.
I end up with cases where it's useful to store data in order to validate it later, though if there's any doubt that I need to override behavior, or validation on set makes sense I don't use fields, but if I used properties both when there is and isn't validation I feel like I lose clarity, not gain it.
Also even if I hypothetically did validation on set other requirements in a significant number of cases would still make me need to validate it again in private methods that used the backing field.
That does help but I feel like the getter is a little under-equipped to handle validation, whereas the private method can make a decision on the invalid data and possibly recover, if it can. Or at very least this seems to make for more clear error messages.
Also I'd argue that validation in the method that uses the field (or property) can be good for readability, because then a programmer won't say "What do you mean I can't set SomeThing to 0, why not?", they'll see right there that the calculation (or whatever it is) can't possibly work with that value. Though the flipside of that is, it puts off errors until the "important" methods are called; sometimes this has helped my designs, sometimes it doesn't.
Better throw a RuntimeException instead of returning a weird string. Try and avoid to create "Stringly Typed" software (look it up!). — Maarten Bodewes49 secs ago
Welcome to Stack Overflow! Unfortunately, questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic here. However, you may find better luck SoftwareRecs.SE. Remember to read their question requirements as they are more strict than this site. — Machavity21 secs ago
@jrh Everything I do as a programmer has a Cost/Benefit analysis associated with it. I always ask the question, "Does the benefit exceed the costs?" In the case of properties, the cost of adding them is so small that the bar is very low for the benefits, and not adding them adds unnecessary risk (however small) that is easily mitigated by the small cost of adding them.
@jrh The reason you reduce expressivity is to simplify. If something only has one semantic purpose, it makes things easier for the programmer coming after you to reason about what you wrote.
That's not necessarily what you do every time. Once again, it comes down to benefits vs costs. If the benefits of making something more expressive exceed the costs, then you go with more expressive.
This is not how many developers nowadays seem to view their work. Many of them seem to prefer being told what to do and to have one right way to do everything, so that they don't have to think. Unfortunately it doesn't work that way, unless you're just some guy coding from a detailed class specification. Then you don't have to worry at all about whether or not to use properties, because someone else has already made that decision for you.
@RobertHarvey Personally, I really enjoy the design aspect, both the UX and the algorithms; I'm also tired of the "one true way" of programming stuff I've read, personally I feel like my "late validation" design makes sense and suits the purpose.
To be honest I'm mostly concerned about this out of what I'd call "professional obligation". In UX design, I'm not the primary audience of what I make, it seems like programming is going in that same direction due to such strong wording being put on blogs like "never do X" and "Y is a code smell" without even really knowing what the rest of the algorithm looks like or why. I'd like to understand my "possible clients" who demand properties for every field, even if I don't necessarily agree.
The setup troubles me and I might be wasting my time, in my experience with different languages it seems like the learning curve for reading somebody else's code is about the same; no matter what language is used or what fancy design pattern of the month is being used, ye olde timing issues and side effects (the same thing that screwed up programs in the 1970s) seem to still be the leading cause of problems.
In the back of my mind I feel like blogs that give out advice without explaining what programming problem it really solves, and how (e.g., with diagrams at least, code, preferably) are kind of dropping the ball.
Maybe they feel like they need to be brief and overly forceful in order to get their point across but this comes at the expense of treating their readers like professionals that need to carefully evaluate what they're saying.
The Whiteboard
The Whiteboard