prabha_friend
Prabhakaran Karuppaih
- Local time
- Today, 17:00
- Joined
- Mar 22, 2009
- Messages
- 876
and Completely dwell into Object Oriented Programming Only here onwards? How difficult would that be to grab the concepts and Develop on the same?
What will happen If I decide to ditch the database?
- Thread starter prabha_friend
- Start date
tvanstiphout
Active member
- Local time
- Today, 04:30
- Joined
- Jan 22, 2016
- Messages
- 315
Presumably you would still need a database of some sort to store your data, no?
You may want to use an ORM = object relational mapper to provide the middle layer between your object-oriented code and your relational database.
Or rather than a relational database, use an object-oriented database - not my area of expertise.
Final advice: go slowly. Try it on a small project.
You may want to use an ORM = object relational mapper to provide the middle layer between your object-oriented code and your relational database.
Or rather than a relational database, use an object-oriented database - not my area of expertise.
Final advice: go slowly. Try it on a small project.
- Local time
- Today, 06:30
- Joined
- Feb 28, 2001
- Messages
- 28,475
Depends on how much object-oriented programming you have done in Access. You have a basic concept already in that you use things that have associated properties and methods. Going into a full-blown OOP environment simply means you will learn more about creating objects that have those properties and methods. But the truth is that OOP is merely ordinary programming dealing with complicated data structures. The innovations are in the things folks have learned about "inheritance" concepts. But the basic operations have been around ever since data structures have existed in programming. For the purists... "Properties" came first. "Methods" came later. But both were available in situ a long time ago. The innovation was mostly recognizing a new viewpoint in how to group things together.
MarkK
bit cruncher
- Local time
- Today, 04:30
- Joined
- Mar 17, 2004
- Messages
- 8,345
Don't choose course of action based on difficulty. Choose course of action based on desire. My observation based on various posts I have seen you make is that you are curious as hell about OOP. So feed your curiosity.
Mastery is difficult. Mastery of the difficult brings immensely satisfaction.
Go for it.
GPGeorge
George Hepworth
- Local time
- Today, 04:30
- Joined
- Nov 25, 2004
- Messages
- 2,384
Philosophically, are you moving away from something in hopes of finding something better? Or, are you moving towards something that appeals to you more than what you are doing now?
In other words, are you trying to replace Access in your toolkit because you don't like it? Or are you attracted to something about OOP that you think will be easier or better or more lucrative?
- Local time
- Today, 12:30
- Joined
- Jul 9, 2003
- Messages
- 16,812
I had a chat with chatty about it and I asked chatty to create a blog post out of our exchange, this is what it came up with:-
Is Microsoft Access Object-Oriented? A Look at Forms and Tables as Classes
As someone who's spent years working with Microsoft Access, you might have noticed that developers don’t often use formal classes in their Access projects. Yet, if you take a closer look at how Access structures its components—particularly forms and tables—it becomes clear that many elements already function in a class-like way. If you're toying with the idea of using MS Access in a more object-oriented manner, this is an interesting perspective to explore.
Forms as Classes in Disguise
In object-oriented programming (OOP), classes serve as blueprints for objects. A class defines the attributes and methods that its objects will have. When you think about it, a form in Access behaves quite similarly to a class:
Properties: Forms have attributes such as the form's size, caption, and data source, much like a class in OOP has attributes that define the state of an object.
Methods: Forms also have methods, which are the actions that can be performed. These methods are defined by event-driven procedures like Form_Open, Form_Load, and Form_BeforeUpdate, which control how the form behaves when it interacts with data.
Encapsulation: Forms encapsulate their own logic, meaning they can store variables and execute procedures specific to that form, much like how a class would encapsulate its own data and methods.
When you open a form in Access, it’s almost like creating an instance of a class. Each form can manage its own data and behave independently, even if multiple forms are based on the same data source.
Tables: Class-Like Structures Without the Behavior
While Access tables aren’t exactly classes, they do have a class-like structure, particularly when you consider:
Fields as Properties: The fields (columns) in a table define attributes of the data, much like class properties. For instance, a "Customer" table could have fields like CustomerID, Name, and Address, which are equivalent to the properties of a "Customer" object.
Records as Objects: Each row in a table can be thought of as an instance of that class, with its own unique set of attribute values.
The major difference is that tables don’t contain behavior. Unlike classes, which have methods to define the behavior of their objects, tables are purely data containers. However, you can combine them with forms or modules to handle the logic and behavior, much like how you'd use methods in a class to manipulate objects.
Why Developers Rarely Use Classes in Access
So, why don’t developers lean into the class-based capabilities of VBA (Visual Basic for Applications) within Access? There are a few reasons:
Simplicity: Access provides an intuitive framework with forms, queries, and reports that handle much of the functionality developers need without requiring custom classes.
Event-Driven Programming: Many developers get by just fine using Access's event-driven system to control behavior. Forms and reports come with built-in methods, so adding custom classes might feel like overkill for smaller projects.
Learning Curve: While Access makes it easy to get started, learning and implementing object-oriented design principles in VBA adds a layer of complexity that not every developer feels is necessary.
That said, custom classes in VBA can be incredibly powerful for more advanced or complex applications. If you're working on a large-scale project, building reusable components, or managing complex business logic, custom VBA classes could help you organize your code better and enhance maintainability.
Bringing Object-Oriented Thinking into Access
If you’re considering using Microsoft Access in a more object-oriented way, it can be helpful to adopt an OOP mindset:
Think of forms as objects: Each form you create is like an instance of a class, encapsulating its own data and methods. You can extend this thinking by using modules to define reusable procedures and functions.
Use classes for complex business logic: While not commonly done, creating custom classes in VBA can be a great way to manage more intricate logic, especially if you're dealing with business objects that require custom methods or behaviors.
Conclusion
Microsoft Access may not be a fully object-oriented environment, but it certainly has class-like elements. Forms act much like classes, and tables function as blueprints for objects. While Access developers don’t often use custom classes in VBA, understanding Access through an OOP lens can open up new ways to structure your applications, particularly for complex projects. Whether or not you take the plunge into full object-oriented programming in Access, it’s worth keeping these ideas in mind as you build more sophisticated databases.
Is Microsoft Access Object-Oriented? A Look at Forms and Tables as Classes
As someone who's spent years working with Microsoft Access, you might have noticed that developers don’t often use formal classes in their Access projects. Yet, if you take a closer look at how Access structures its components—particularly forms and tables—it becomes clear that many elements already function in a class-like way. If you're toying with the idea of using MS Access in a more object-oriented manner, this is an interesting perspective to explore.
Forms as Classes in Disguise
In object-oriented programming (OOP), classes serve as blueprints for objects. A class defines the attributes and methods that its objects will have. When you think about it, a form in Access behaves quite similarly to a class:
Properties: Forms have attributes such as the form's size, caption, and data source, much like a class in OOP has attributes that define the state of an object.
Methods: Forms also have methods, which are the actions that can be performed. These methods are defined by event-driven procedures like Form_Open, Form_Load, and Form_BeforeUpdate, which control how the form behaves when it interacts with data.
Encapsulation: Forms encapsulate their own logic, meaning they can store variables and execute procedures specific to that form, much like how a class would encapsulate its own data and methods.
When you open a form in Access, it’s almost like creating an instance of a class. Each form can manage its own data and behave independently, even if multiple forms are based on the same data source.
Tables: Class-Like Structures Without the Behavior
While Access tables aren’t exactly classes, they do have a class-like structure, particularly when you consider:
Fields as Properties: The fields (columns) in a table define attributes of the data, much like class properties. For instance, a "Customer" table could have fields like CustomerID, Name, and Address, which are equivalent to the properties of a "Customer" object.
Records as Objects: Each row in a table can be thought of as an instance of that class, with its own unique set of attribute values.
The major difference is that tables don’t contain behavior. Unlike classes, which have methods to define the behavior of their objects, tables are purely data containers. However, you can combine them with forms or modules to handle the logic and behavior, much like how you'd use methods in a class to manipulate objects.
Why Developers Rarely Use Classes in Access
So, why don’t developers lean into the class-based capabilities of VBA (Visual Basic for Applications) within Access? There are a few reasons:
Simplicity: Access provides an intuitive framework with forms, queries, and reports that handle much of the functionality developers need without requiring custom classes.
Event-Driven Programming: Many developers get by just fine using Access's event-driven system to control behavior. Forms and reports come with built-in methods, so adding custom classes might feel like overkill for smaller projects.
Learning Curve: While Access makes it easy to get started, learning and implementing object-oriented design principles in VBA adds a layer of complexity that not every developer feels is necessary.
That said, custom classes in VBA can be incredibly powerful for more advanced or complex applications. If you're working on a large-scale project, building reusable components, or managing complex business logic, custom VBA classes could help you organize your code better and enhance maintainability.
Bringing Object-Oriented Thinking into Access
If you’re considering using Microsoft Access in a more object-oriented way, it can be helpful to adopt an OOP mindset:
Think of forms as objects: Each form you create is like an instance of a class, encapsulating its own data and methods. You can extend this thinking by using modules to define reusable procedures and functions.
Use classes for complex business logic: While not commonly done, creating custom classes in VBA can be a great way to manage more intricate logic, especially if you're dealing with business objects that require custom methods or behaviors.
Conclusion
Microsoft Access may not be a fully object-oriented environment, but it certainly has class-like elements. Forms act much like classes, and tables function as blueprints for objects. While Access developers don’t often use custom classes in VBA, understanding Access through an OOP lens can open up new ways to structure your applications, particularly for complex projects. Whether or not you take the plunge into full object-oriented programming in Access, it’s worth keeping these ideas in mind as you build more sophisticated databases.
Last edited:
- Local time
- Today, 12:30
- Joined
- Sep 12, 2006
- Messages
- 15,934
Don't forget that Access makes lots of things very easy. Data binding, data updates, continuous forms. It will be enormously difficult to programme that all in. I keep trying it out, and the data binding/continuous forms stuff just seems so difficult to achieve. If I could get that working, I think I could make some progress.
- Local time
- Today, 04:30
- Joined
- Aug 30, 2003
- Messages
- 36,178
I had a similar experience trying to learn C#, recommended by our IT guy. I could pass data from/to the SQL Server, but a form/subform situation? It was difficult enough to make me give up. But then I'm an old guy and that's a new trick.
NauticalGent
Ignore List Poster Boy
- Local time
- Today, 07:30
- Joined
- Apr 27, 2015
- Messages
- 6,555
About a year ago, I was asked to provide a paper on what would be needed to accomplish everything Access could do. To speed things up, I consulted ChatGPT. I cant provide the paper I wrote, but I will share the initial response I got:
- Local time
- Today, 07:30
- Joined
- Feb 19, 2002
- Messages
- 45,109
@prabha_friend I'm actually disturbed by your question. As the others have said, you can't actually "ditch" a database unless you have no data to store.
You might also want to read about the negative aspects of OOP. As chatty has pointed out, Access is already sort of Object Oriented. To make it go all the way, makes the code virtually unintelligible to anyone who isn't totally into OOP. I've only come across two apps that were developed by Access haters and those two apps were a nightmare to understand. Possibly because neither programmer had a clue what he was doing. I ended up totally recreating both. Luckily they were not large. It is simply impossible to follow the logic in an app where ONE LINE OF CODE is nested 7 levels deep. I simply don't have enough fingers to follow the flow even when I print out the code.
If you are looking to monetize your skills, then you should study and learn what potential employers are looking for and I'm pretty sure it isn't "OOP".
You might also want to read about the negative aspects of OOP. As chatty has pointed out, Access is already sort of Object Oriented. To make it go all the way, makes the code virtually unintelligible to anyone who isn't totally into OOP. I've only come across two apps that were developed by Access haters and those two apps were a nightmare to understand. Possibly because neither programmer had a clue what he was doing. I ended up totally recreating both. Luckily they were not large. It is simply impossible to follow the logic in an app where ONE LINE OF CODE is nested 7 levels deep. I simply don't have enough fingers to follow the flow even when I print out the code.
If you are looking to monetize your skills, then you should study and learn what potential employers are looking for and I'm pretty sure it isn't "OOP".
NauticalGent
Ignore List Poster Boy
- Local time
- Today, 07:30
- Joined
- Apr 27, 2015
- Messages
- 6,555
At one point in the ongoing "conversation" FileMaker Pro and Service Now were mentioned as well.
prabha_friend
Prabhakaran Karuppaih
- Local time
- Today, 17:00
- Joined
- Mar 22, 2009
- Messages
- 876
Hi All,
Thanks for your elaborated replies. The No.1 reason I want to shift to OOPs is that I don't want to heavily depend on any software to preexist to run my solutions. Just thought of creating my own my file formats and everything if it is required. I know it's a day dreaming so far. But I surely want to give it a try. Just imagine... How Good it sounds when a person questions you like...
"On Which software you are developing your solution?"
and your reply is...
"I make my own
"
Thanks for your elaborated replies. The No.1 reason I want to shift to OOPs is that I don't want to heavily depend on any software to preexist to run my solutions. Just thought of creating my own my file formats and everything if it is required. I know it's a day dreaming so far. But I surely want to give it a try. Just imagine... How Good it sounds when a person questions you like...
"On Which software you are developing your solution?"
and your reply is...
"I make my own
"- Local time
- Today, 07:30
- Joined
- Feb 19, 2002
- Messages
- 45,109
OOP is a style of programming. Certain languages are optimized to help you with this particular style.
The current "hardware/software" isolation model is a web page. If you can create a generic web page - i.e. don't use any features specific to a single browser, your code can run on any platform.
LarryE
Active member
- Local time
- Today, 04:30
- Joined
- Aug 18, 2021
- Messages
- 802
The cortex of your brain will overheat and explode. Please do not do this.
- Local time
- Today, 06:30
- Joined
- Feb 28, 2001
- Messages
- 28,475
Naw, he doesn't live in the USA so the overheated political situation won't interfere with what he does. Lower ambient cortex temperature for starting point so less likely to explode.
LarryE
Active member
- Local time
- Today, 04:30
- Joined
- Aug 18, 2021
- Messages
- 802
Clinical studies show attempting to understand OOP produces extreme heat and pressure resulting in cortex explosion no matter where you are, but these studies were first reported by CNN so there you go.
- Local time
- Today, 12:30
- Joined
- Sep 12, 2006
- Messages
- 15,934
I assumed it was me just not understanding, but maybe not.I had a similar experience trying to learn C#, recommended by our IT guy. I could pass data from/to the SQL Server, but a form/subform situation? It was difficult enough to make me give up. But then I'm an old guy and that's a new trick.
