Object Oriented Programming is not what I thought - Talk by Anjana Vakil 

Thank you

Dude you're a god or somethin

thank you!!

Was 90 seconds in and about to leave before I saw this comment

I was about to say at the 14 minutes mark, and goes for a minute or 2

Yes, "Code With Huw" has actually started a series about the original ideas of OOP. He's using the Digitalk SmallTalk V manual from the 80's, the one Alan Kay recommended, and translating it to Squeak for the modern audience. Cool stuff!

I started Learning programming at the age of 22 and my first programming language was small talk and a year later C++. lol

It is also useless. ;-)

@@lepidoptera9337 no, it's quite useful.

@@Gnaritas42 Dude, if you want attention, then just say so. ;-)

me too! This analogy with biology helped me to see the things in another way. It makes more sense than plato theory, and others that ussualy are used to explain OOP.

Messaging is an implementation detail that has nothing to do with the object concept. Everything that can be done with messaging can be done faster, easier and better with function calls. The only valid reason for messaging is the use case of distributed systems (spatial or temporal). On a single CPU that is running one copy of the code messaging is a foolish concept.

@@lepidoptera9337 that might be true but I don’t use FP so messaging is the way to go for me. It does make the code clearer too. And I might make microservices from it one day anyway. And it is the only way to make objects communicate in an uncoupled way… in my example it is angular services that communicate via messaging (events). If I don’t do it that way I get a circular dependency. But you are welcome to suggest a better solution for this particular problem. And don’t say FP. I don’t have the time to learn FP now. The project needs to be finished in 6 months.

@@paulholsters7932 Nobody can stop you from doing idiotic things that you don't understand. That messages can't lead to circular dependencies is plain false. Messaging has nothing to do with the dependency problem to begin with. If you don't know how to avoid such situations, then you are simply not an experienced programmer and the problem is caused by you in the first place. If you are planning to use microservices one day, then you better design for them from day one. That's just architecture for dumies. FP doesn't exist. I don't know why you would even think that I am talking about FP. Is it because all you know about design patterns and paradigms is these two acronyms? OOP and FP? Is that it? In that case you need to take a CS 101 class SAP.

@@lepidoptera9337 No messaging allows more flexibility as the object can store the message, pass the message out, replace parts of the message, add parts to the message, etc... Messaging is just late bound function calls if you understand LISP quote then a message is a quoted version of a function call, and the overhead can be removed via a just in time(dynamic compiler) perhaps. Single CPUs are a bad idea, so is splitting RAM & CPU, both RAM & CPU are made of silicon a lot of your computer is idle where if you merged RAM & CPU into some sort of a celluar-automata type thingy you can have a lot of processes/objects everywhere.

No, you don't. You just think you do, which makes you extra dangerous. :-)

What gets me with many OOP languages is the concept of a class which is totally in line with Linnaeus whereas in modern biology we think less about the idea of "a bird" being a specific class and more as a collection of dino-traits and a collection of birdy-traits that come together to make the thing we call "a bird". Which is more in line with how some more recent languages (like Rust) handle binding behaviour to data.

Cancer must destroy the cells. I.e OOP

Well, the message passing between your cells and organs are OOPing the f out... for sure.

😂😂😂

Are there any articles or videos that analyze in depth Erlang versus how Smaltalk does things today?

Metaphors are for idiots and that is simply not where OOP came from. OOP came from resource optimization on machines with small memory footprints.

@@lepidoptera9337can you expound more on that?

@@lepidoptera9337 Dude, if you want attention, then just say so. ;-)

@@TheCidraque That's my line, kid. Please learn the history of CS properly. At best classes are telling the compiler when to reuse functions. They are also completely unnecessary and the compiler strips all of that information from your code completely. Your CPU never gets to hear about your classes and objects. In effect OOP is, for the most part, a (pretty poor) program documentation technique. ;-)

what about sync and reactive paradigms ? ,(in some sectors they are the most used and popular ones , thinking of vHDL)

on a side note i would have tought that after 20 years of "your doing it wrong" - OOP seminars and presentations , they would have given up by now and realized that OOP cant deliver , besides that i know quite a few people who all came to the same conclusion: apparently you need a degree in geneology and phylosophy more than a degree in math and programming to succeed at OOP if such a thiing is even possible., and a lot more that just realize oop is bad, and thats the only paradigm that ive ever heard this , for , never heard a functional programmer say: " danm procedural codebase , one should never program procedurally, nor have i heard a procedural programmer complain about functional or any other paradigm but ive heard them all complain about oop , prolly theres a lessen in there somewhere,. and yes writiing gui applications can be done without oop, QT is prolly the most OOP oriented toolkit out there , and am able to blackbox it and writer procedural code around it that works perfectly , and i have to type a whole lot less code for it.

@@DonAlcohol I don't think you grasped the point here: syntactical sugar reflects the different methods by which humans think, and the methods by which humans think can vary in concert with the optimum system model. Some of us wield all, some of us wield few, and some of us use a paradigm and some resist it. I suspect that you're trying to make the case that the kind of work you do is easier to write and more productive by not using OOP. That could mean the category of work you perform does not include the category of simulations. I prefer the pascal architecture we used pre-oop. Others prefer the functional architecture we used before pascal. NOw, you brought up reactive, which of course is a failure of the architecture of browsers given that open source gains that led to reduced costs and a vast ability to learn from and copy one another's code, also led to open source market for resistance to major improvements. I see the browser based tech as highly democratic and cheap per se, at the cost of spending billions per year and hours after hours because we don't have a compiler that does all the work for us, and so we compensate with all these 'hacks' we are self impressed with. The optimum language is already known. The way we compose software within it follows general design patterns. There have been minor improvements in software design over the decades largely for no other reason than decrease in cost of cycles, memory, and storage. And each generation re-learns the same things and tries to reinvent them, but they're all just basic design patterns.

@@TheNaturalLawInstitute no i actually understand what you mean and with the firs reply i just wanted to mention that you forogot some in your listing , (including a verry common one , wich is sync , the te paradigm used (besides functional) in spreadsheets. and with the second comment i wanted to point out that there is 20years of guides and presentations with the topic "why you are doing OOP wrong, and what is the correct way everybody seems to miss.. only to find that every guru and OOP connaisseur seems to have his own interpretation off why OOP does not deliver what it promises to. its never the "fault of OOP" but always some rule or guideline the users seem to miss or implement wrongly, but every GURU seems to contradict the otherones in how to do it right. (just as OOP does contradict its own definitions of what the stuctures are supposed to be, you dont have do go any furter than a singleton, its an oxymoron, read the definition of class then read what a class is supposed to be used for then realize on how many fronts a singleton violates those definitions) , and i hate using OOP myself but i dont forse other people to not use it , I know of verry few occasions where OOP is actually the best way of thinking about a problem , one of wich is in markup, and i mean (lets say HTML) the notation itself makes sens using some sort of objects that are grouped , the rendering / processing of that ML can be done better with procedural , ANSI (terminal markup and positiioning , for instance is a procedural way of markup but one as to agree thats less intuitive than html/css is to keep on top of things but thats about the only one. and as a last one: if you try to emulate realworld thinkg in a programming anguage and you link the way we categorise things similar to the abstraction in OOP, you should try to categorise living things,(or just humans for that matter) and see at what level a straight hiearchy breaks down the reason you almost cant make a hiearchy that makes sense at all and doesnt break the branching of a hiearchy , is the same reason abstractiion and encapsulation in OOP fail every time for a project in actiive development . and run a textsearch (with fzf or so) on a OOP project of some size for the words controller, handler,setter,getter,helper,factory,abstract, (or how manny times a button with the label "connect" actually runs a method in some subclass of connectionhandler while a func connect() would make allot more sense , if it succeeds great if it fails it cn throw an exeption, but it doesnt have to call amethod inside connectionhandler.connectionfailedhelper.conectionexeption)

@@DonAlcohol I dunno. OOP does what we want it to: simulations. Way 'back in the day' I wanted it before I knew it existed. Because I was writing simulation games on the first consumer computers. And I kept running into problems. IMO complaints about OOP come from people who haven't written anything large, that has to be broken down into responsible components agents, each of whom has to make decisions that can be driven by messages or events. There are a limited number of language paradigms available, and a limited number of design patterns possible, and we all know what they are and they serve different purposes at different scales. My main concern is that the browser era is teaching people to write bad code with bad tools that costs many billions of dollars. Now there is some tradeoff here between the economics of the current era's disposable software and the past era's operating systems (long-running) and applications (long-running) and now server (can be either) and browser (short running). But I've known for more than a decade how much time and money are wasted, people are employed, because of bad tech. So, you can either write in every paradigm or you can't. You can either choose the tool or you can't. I don't write embedded software. I don't write drivers. I don't write operating systems. I design platforms and applications, and (you don't know me) I built and sold two of the largest privately held software consulting firms in the country. I don't design much any longer, and don't program much any longer - it stopped being interesting. But Uncle Bob is pretty much right about everything and his advice stands. We will converge on one language. We know what it is. We will keep inventing a 'few' new tools that take advantage of faster processors and more memory and more distributed systems, we will keep inventing a few new patterns, and there are two generations we can at least envision coming down the road after the current bayesian and future baysian agent predictions. When we get to bayesian transaction I hope someone has fun with that one.

Abstraction, Inheritance, Encapsulation, Polymorphism. Am I on the right path? :D

garbage collection is a mistake btw. pascal had it right the entire time, use pointers only in those cases where it makes sense and don't use them anywhere else also microsoft somehow managed to take the notion of references from C++ and then complete break the functionality in C#, that is probably the main reason everyone is so gang ho on functional all of a sudden

Sounds reasonable, is it something knew as "practice"?

> _"Use OO modeling to find the right places in your application to put boundaries. Use FP techniques within those boundaries"_ thanks a lot for summary :)

Kind of object-ish things that are almost an objects. I felt stupid every time she got vague and fluffy.

"It sort of moves a little bit in that direction." Immediately after I unpaused after my previous one.

Sorry... I'm trying to help not troll you... But Anjana describes "late binding" a lot of times in this talk which is (and I'm massively oversimplifing) related to polymorphism is OOP. `lateinit` in Kotlin is more of a workaround to avoid having "null pointers" (it's not that great a workaround because it's just replacing `null` with something that smells very very strongly of `null` but isn't explicitly called "null"). The two aren't particularly related.

That's because there are hardly any good use cases for OOP in reality. Static GUIs work well, but then... who gives a shit about what happened on the Amiga 30 odd yeas ago? It's 2023, for heaven's sake. I do agree with your last sentence... until a requirement changes and it becomes important to have the method in one particular class (and the sandwich always lands on the buttered side)... and then the great refactoring begins.

She certainly knows less than nothing about it. ;-)

you should create a video about this. It sounds interesting.

@@leaoaugusto Yes and a song, animation. In the style of SchoolHouse Rock.

I can understand that Mr. Alan Kay regrets coining the term "object" and what she means when discussing verbs vs nouns, but I think at this point OOP is not what they want it to be. What they want should be called a different name: microservices? Message Oriented Programming? I hate when people try to redefine a well established concept just because they had an epiphany about a better way to do things; even if the original intention was different (Mr. Alan Kay's original plan for OOP) the fact is, OOP is OBJECT oriented programming not MESSAGE oriented programming. In JAVA I create objects, not verbs... I don't pass messages; message is not even a primitive or reserved word in most OOP languages. And there is a perfectly valid use for OOP for many, many tasks... not every problem has to be solved with the same tool (or paradigm). When can solve problems with a "cell -message oriented" paradigm, but we still have lots of problems worth solving with OOP, as most people understand it, there's no need to redefine the concept in such a contrived way as to make OOP "not really about objects". Coin a different term and use that style of programming when it is appropriate.

When you look at it that way it makes so much sense. Just like how every sentence has a noun and verb, every statement has an Object and a function / method

That is not so. Functional programming is stateless, but what people are doing in practice is not functional programming. There is, technically, no such thing as functional programming. In computer science the pure function paradigm was invented as a mathematical proving technique and it has turned out to be extremely useful. What we are doing when we are programming, however, is not the same as theorem proving. The overwhelming use of computers is as sources of complex side effects and that is, of course, not stateless (because we want the computer to change the state of the environment). Encapsulation is a documentation technique. It has absolutely no consequences on the actual code execution level.

@@TapetBart When was the last time you got paid by an employer to prove a theorem? ;-) One can not program without side effect. That's physically impossible. At the very least your computer consumes power. Even the most trivial "useful" program like "Hello World" changes its environment by producing output. You simply don't know what you are talking about. ;-)

@@noobdernoobder6707 There are no stateless programs. At most there are functional programs that keep a (now useless!) copy of the original data in place, only to delete it later. The only relevant side effect of that is that it wastes memory. Everything else is completely identical to a program that does not keep that copy. Are any of you guys even THINKING about what it is that you are doing? I don't think so. Most people seem to treat "computer science" as a tribal sport these days. ;-) I have no idea how this is supposed to impact parallelism. Keeping multiple copies of data of which only one copy is valid at any given time during the execution of a program has nothing to do with parallelism. It doesn't solve any of the hard problems of parallelism, like dependencies, runs, locks etc.. Nothing does. That's why smart people avoid parallelism like hell. Take it from me... I have spent years of my life with programmable hardware, where every single operation is parallel with every other operation. If you think that's "fun", then welcome to a special kind of hell for software engineers who just don't know better. ;-)

This is wrong.

@@virus3103 Almost every bullshit that random people are dropping on the internet is wrong. What are you going to do about it? ;-)

He loved it and said Erlang is ironically the only language, that he would consider OO today.

Objects in an OOP language are hints for the compiler for how to organize its compiler tables and they are tools of the architect to document code structure and to limit access of the individual programmer in the team to private data that are also disallowing the modification of interfaces. Objects don't exist in the executable. Neither of these functions has anything to do with grammar or agency (other than the differences in agency of the architect/programmer paradigm, which has everything to do with business structure and nothing with programming).

Spoken like a FP purist who ignored everything except the things that could be taken out of context to prove their point.

@@saritsotangkur2438 I hope you are having a good day and many better ones to come.

Yes, that is bullshit. Alan Kay had nothing to do with the invention of OOP to begin with and he simply misunderstood what it was trying to do. Almost no implementation of OOP uses message passing. Those that do contribute nothing to the solution of the problems that OOP was initially trying to address.

me too bro

Me too!

+1 😊

+1

Why is that a problem? In C++ absolutely everything that belongs to the program (data and code pages) can be accessed with a pointer. The language implementation does not prevent this by design, otherwise you could, for instance, not write operating systems with it. If what you want is a language that is not Turing complete, then C/C++ are not the right choices.

You are simply running up against the fact that OOP can, in the best case, describe tree-like dependencies, while in real life dependencies in complex software tend to form graphs.

Yes, let's master both. She's right about the 'what the object does' vs. 'what data and structure'. Monads are good to understand, whether from an OO language or an FP language, because they are what's she's describing as little chunks of data with process around them. 🤓

BTW Monads in Haskell are kind-of inverted OBJECTs.

Yes, kinda. If you want to program in OOP the way Alan Kay imagined it, then yes it is a form of event driven architecture. However, it is not the observer pattern. In OOP the caller knows who to send the message to. In observer pattern there is no caller per se, the caller instead notifies other objects that have subscribed to it of it’s changes.

@@saritsotangkur2438 Thank you for your reply!

@@saritsotangkur2438 Events then? Since C# Events doesn't know who's listening or subscribed

exactly

> _" linguistics and code concepts"_ thus reminds me of the talk given by co-creator of julia language.

YoUR Soo muCh SmartS

Agree but at different fields and different level it depends on the requirements.

8:41 she is summarising the original idea by Alan Kay

@@pik910 Kay is not the inventor of OOP by any count. His ideas about it are not even mainstream and have little, if anything to do with the reality of why it was invented in the first place.

Seriously, I feel the same........OOP object has nothing to do with objects of real world........instead it is variable and function in one package as simple as that

@@lepidoptera9337 He is the principal designer of Smalltalk. Mainstream ideas of OOP today are misnomers.

@@drcl7429 Smalltalk is an aberration that nobody of importance uses. ;-)

It's 100% incorrect to begin with. Procedural programming is focused on action while OOP is just a bean counting strategy that gets stripped out by the compiler completely. The compiler can't strip out procedural code which actually does something (and it doesn't, unless it is dead code, which is rare).

> _"Procedural programming is focused on action"_ @@lepidoptera9337 yeah, exactly. I was taught in the class that "PO focuses on functions, OO focuses on data"

Good luck with that strategy. See you are your next refactoring party. (Unpaid overtime, of course.);-)

Yes. They are putting too much effort into redefining OOP into something it is not, just for the sake of redemption of its original author's intentions. There are more appropriate terms for the style of programming the presentation illustrates. I've also heard about this paradigm referred to as "Agent Oriented Programming".

a method is just a low level programming construct. a routine that can be executed on the processor. OOP employs this construct to implement collaboration between objects. As soon as you are thinking about Objects you have jumped up into a higher abstraction level where objects collaborate by communicating with each other (hence the term messages). Although it is implemented on processor as a method invocation at a lower level of abstraction. hope that clears things. What you are referring to are just two ways of control flow. One is imperative (method calling) and other is reactive (handling messages as events), both of which alan kay refers in this talk ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-QjJaFG63Hlo.html.

Sounds more like a lack of software engineering experience than an oop vs actor model issue. If you want to do concurrency then use concurrency patterns. If you don’t have the concurrency requirement then don’t. Don’t apply the wrong pattern and then say something sucks, that’s a strawman argument.

Every piece of bad code in the world is a practical example of that. There simply is no such thing as "a bug". There are only people who don't know what will actually happen when they write code. A bug is the disconnect between the programmer's beliefs about the language and the compiler and the compiler's actual architecture. ;-)

@@lepidoptera9337 this is one brilliant definition of a bug.

she talks with like dozen of organs.

OOP is not language dependent. It is always just documentation. The final binary does not contain any traces of your OOP code, if your compiler is any good.

​@@lepidoptera9337I was about to say "Java leaves plenty of traces of OOP in the binary"... but then I noticed you said "... if your compiler is any good" ;)

@@edgeeffect Java was an idiocy. It's "write once, deploy nowhere" for starters. It provides next to no useful additional abstractions compared to let's say C++ but suffers from the same problems (complex types are passed by reference... welcome to recursion hell...) without allowing low level programing (no, pointers are a real feature, they are not a mistake) etc.. It was basically language design during an amateur hour of sing as much as you want CS Karaoke.

You are mostly telling us that you have no experience in software design. Let me give you some attention then. ;-)

@@noobdernoobder6707 You got it... objects are not good representations of most problems and compilers remove objects completely, which means that OOP is basically just a really bad documentation technique that writes a lot of boilerplate to express something that the programmer usually doesn't even need and want. Architects like OOP, though. Why? Because it allows them to micromanage interfaces and they can bash the actual coders for violating "their" design. The biggest problem with objects is deep inheritance, which locks the code into a rigid structure that may not be appropriate. Even if the architect got the initial class hierarchy "right", changes to the requirements can break the class hierarchy in really nasty ways, requiring a lot of refactoring, which is confusing and violates the "never break a working system" rule.

@@lepidoptera9337 Thanks for the attention! Not sure what qualifies as experience tbh. Did I write class diagrams? Probably did, a long time ago. Wrote a lot of sequence diagrams (hundreds). I also wrote countless classes. Does that count? Anyway, I'm not saying i'm not the world's worst programmer, but I'm curious whether anyone did any studies testing claims about OOP. I totally get this phenomenon you wrote about, that architects can use class (or other) diagrams to show developers how thet did stuff wrong. For a mere 9 months did I work with a software architect, and stuff absolutely moved slower - I suspect that the guy was really bad though, but the one datapoint I have is not saying good things about architects.

@@ardeleanvladgeorge7493 My experience with (rigid) architecture is that it clashes with the reality of requirements change. Most complex projects are actually exploring the question "What does the customer really want to do?" while they are developing the solution. So unless the architect has godlike visions of the future even the best intentions and the best intellectual execution of the original requirements will necessarily cause problems in the future... IF the original architecture is too keen on "getting it absolutely right". Techniques like OOP that are trying to lock the architecture in too early are necessarily suboptimal in a dynamic environment. They look good on paper before they are being committed to actual costly work on the code, but can easily backfire by making large scale changes necessary at later stages. I put myself through refactoring hell once (on a single person project!), and that taught me to be more open than perfectionist. In the end I rewrote most of the top level structure in a couple of days from scratch. It was easier than trying to fix the bad choices I had made in the beginning incrementally.

Relax

That's only when you learn programming in India.

Bwahahahah

@@peach_of_justus honestly, I don't remember. But there's a reason you ask. Let me know your thoughts.

IMO the core concept of object-oriented programming is parameterization of behaviour rather than just data; by this, I mean passed in behaviours that are not known at compile time, like how data values are not known at compile time. Messaging is simply invoking a parameterized behavior. "Recursion on the concept of program" is composing parameterized behaviours into more behaviours. Late binding is another way to describe this same concept. First-class functions are an alternate way to conceive of parameterized behaviour.

I mean C++ is essentially a oop version of c. It took great parts of c and built upon it to help programming enterprise applications. C# took that same premise but did it to c++. They all have their place. Same with the paradigms. I think people look to much to these concepts as the end all be all and say one trumps another. When, In reality they’re all just different tools and practices that are a part of a bigger system.

I think most advocates of Pure FP (ie no OOP at all) have never dealt with a huge codebase or gamedev before. OOP has problems when using it at a small scale but on big programs I couldn't imagine using anything else.

Speaking as a Smalltalk developer here I find I can quickly refactor classes using the tools Smalltalk has available. In smalltalk if you mistype a method name the method will not compile. There can still be run time errors, however. For instance, you could put 2 objects of different classes into a collection, and then call a method on all objects in the collection. So a message could be sent that cannot be executed because the object does not have a method protocol for that message. In that case, in Smalltalk at least, the program does not crash but "doesNotUnderstand: " gets called on that object. So that gives you some leeway into making your system robust. But the real key is just programming and debugging in a way that will not run into these errors. Unit testing can help with that.

@@zenchess Yeah, except for not throwing an exception this sounds exactly like all those dynamically typed languages to me. Having to write unit tests for things other languages just check in the compiler for you. In what cases does smalltalk detect missing methods on "compile" time? When the type of a local variable can be inferred? Then it is at least better in that point than other dynamically typed languages, but still. I prefer strict static typing when possible. (With type inference and all the nice handy things of course.)

Late binding is orthogonal to dynamic typing. All it means is that the function (method) being called is not set at compile time. Whether it is typed checked or not is up to the language to decide. Java type checks whereas Python doesn’t.

Message passing has exactly the same problems as threads. All concurrent systems have them. They are not "just" a consequence of "stupid implementation". Concurrency removes the abstraction that there is no time in computing. And once you let it in, it will cause all kinds of unpleasantness because "who's first" suddenly matters.

@@lepidoptera9337 what I meant by threading is its implementation, the API developers are using, I assume we know it’s a must if you want to use more CPU cores; yes behind a scene everything is threading if you do. but the thread implementations in JAVA, C++, etc and the context switching, dead locks, etc has pitfalls. actor model solved this assuming we know it’s using threads behind the scene but it hides it from us.

@@masoudesmaeilian5083 Parallel processes that don't communicate are perfectly safe, but very limited, of course. It's always the interaction that makes life difficult. Deadlocks and races are not implementation dependent. They are inherent in concurrent designs. I once talked to a CS professor who had implemented two concurrent languages and who was considered a leading specialist in the field. He told me that he had basically given up on the idea that one could make concurrency easy and safe. One can always make it work, of course, and I have done it often enough in my work. It's just no fun to debug these systems and it might not get significantly easier, not even with new languages. I hope I am wrong.

Because "modular" is far more general than OOP. OOP was originally meant to put limits on modularity to allow for automatic optimization.

@@lepidoptera9337 thx good to know. I find the expression OOP confusing as I struggle to understand what it means.

@@stevenlightfoot6479 In its most basic form it means that we are packaging data and functions that act on data together and we call that a class. The problem with that is that very often the most important functions in our code are not just acting on one data structure but two or more, i.e. the association of functions with any one data structure is ambiguous at best or counterproductive at most. Consider something like a dogClass. Every dog object has a name, date of birth, an owner, a vet and maybe even a dog walker. Where do you put the healDog() function? With vetClass or the dogClass? Even worse, both the owner and the dog walker are walking the dog and the owner has to pay the dog walker. So does walkDog() belong to dogClass, ownerClass, dogwalkerClass or neither? Are there multiple versions of it (oh, horror!)? Who calls payDogWalker() at the end of walkDog()? You may have to go to absurd lengths to sort these kinds of things out by calling dogWalkerClass.invoiceDogOwnerforDogWalkActivity() as part of dogClass.walkDog() or something similar just to allow messaging between two classes (dogOwnerClass and dogWalkerClass) that are being references by dogClass data. Problems like these can snowball very quickly in large OOP projects if the architect didn't think dependencies through all the way. Or let's say the architect is really, really good and it all works but now the requirements change and suddenly there are new dependencies that didn't exist before. Suddenly it doesn't matter what object structure worked well in the past. That's why it's dangerous to make the kinds of structural decisions that OOP requires early in the architecture phase of a project. They usually don't tell you that in OOP classes, though. The usual examples for beginners have trivial dependencies which hide real world problems.

yeah you know me

@@thewarriors3048 damn i posted this 3mo ago lol. glad someone gets it