Looks like crossing the border Lot to me and seems valuable Will Download and try to understand Thanks💫
@seanmackenziedataengineering3 ай бұрын
Oh yes, this topic takes you to the "other side" of development. OOP can be very fun.. and useful! Download added mackenziemackenzie.com/downloads
@serdip3 ай бұрын
Thanks for posting this very interesting and informative video. It would be great to take the discussion to the next level by explaining interfaces and their implementation. For this example, I envision an interface for Candy objects , ICandy, and for CandyBox objects, ICandyBox. Also, if we add a Capacity property to the CandyBox object, then the AddCandy() method could raise a custom event BoxFull to display a message that the current instance of CandyBox is now full. Subsequent calls to AddCandy() might perhaps quietly ignore inputs. Database tables and Excel ranges are among several ways of persisting instances of a class between sessions. I used such a technique in a large Excel application that modeled industrial ergonomic risk factors. Thank you kindly.
@seanmackenziedataengineering3 ай бұрын
Thanks for sharing!
@zoranstojanovski84074 күн бұрын
To bad Access has no option to bind class collection to form, so when you add Candy you can view in subform, and when you click submit button to add candy box in a main table and all candy's in separate table. In that way user can decide to save or not changes like word document.
@seanmackenziedataengineering2 күн бұрын
Interesting observation. I think you're right - it would be nice to be able to do that. Some things you can do are to load other objects like listboxes and combos on the fly. In the past, I did solutions where users did input on a subform in some kind of temp table. Then, they would need to click a button to commit the changes (basically append them to the production table). This is useful in some use cases. Thanks for sharing!
@simondodge97333 ай бұрын
Interesting. I am still trying to get my head around exactly how I would use objects in my database (I am an old mainframe programmer, so have built a database without OO programming, LOTS of VBA code ). I have many tables , most with many fields. I'm trying to understand what the benefit is to me of using class objects.. IS there a performance difference ? IE do all the records get loaded into memory once and then replace IO with memory access until I update/commit an update ? It would seem that I am going to need as many objects as I have tables where each object matches a record in a table (each field in the record becomes a property of the object).
@seanmackenziedataengineering3 ай бұрын
In some ways, my background might be similar to yours in that I used procedural programming for the vast majority of my functionality. It works great, and you don't really _have_ to use OOP for the vast majority of tasks. However, one major overlap between OOP and Procedural started happening when I would create a meaty module for some complex system. Eventually that module would get some spice on it in the form of Public or Global variables that I needed to recall over and over while I performed a particular function. Sometimes I actually needed _two or more_ of that meaty module running at the same time while some batch procedure ran. Sure, I could write workarounds that stored values here and there while I tried to use the module twice.. but it just got crufty. That is when I discovered the class module.. I could take that meaty module and turn it into and class and run two or more of that logic at the same time from form VBA or some other module, maybe comparing values or committing each one's data at the desired time. Then I discovered that I could break that big class into smaller ones that could have their own functionality.. then eventually OOP came naturally.. and yes, you can avoid a ton of your IO and dependency on disk and network by having some nice performant objects in memory. It is like night and day in terms of performance.