I'm an object-oriented beginner.I'm having trouble naming the classes that generate the data model?
What do you call object-oriented classes that generate, edit, and delete models such as the following?Also, what would be a good way to learn how to separate responsibilities for these object-oriented classes?
#This class is the "data model".
Class User():
self.name=""
self.age = 0
# I'm worried about naming this class.
Class UserFromDatabase():
self.db = DBCclient()
def make_user():
data=self.db.create({table:"user"})
return User (data)
default_user(id):
data=self.db.get({table:"user", id:id})
return User (data)
def delete_user(id):
self.db.delete({table: "user", id:id})
......
I would appreciate it if you could let me know.
python
There seem to be several names that call objects like UserFromDatabase.
In terms of domain-driven design and clean architecture
Pull data out of a permanent system (such as RDBMS) and
The class for searching, retrieving, and building instances of Model is called Repository.
Another well-known name is DAO (DataAccessObject), which was raised in the design pattern collection called Core J2EE Patterns.
However, the role of DAO is to prepare the persistent system itself for future replacement.
So basically, DAO has the idea (tendency) of preparing only one for the persistent system.
The code that only writes database operations for User may not be sufficient.
Therefore, in this case, I think it is appropriate to use UserRepository.
Here's how to learn how to divide object responsibilities.
It's good to read a book on design patterns and architecture.
In particular, the design pattern directly tells you how to do it well in a catalog, so it's good for you to learn it first.
In the Python code coding convention, pep8 says that the class is named as follows, but only CapWords (capitalize and connect the initials of words):
https://www.python.org/dev/peps/pep-0008/ #class-names
Class Names
Class names should normally use the CapWords convention.
The naming convention for functions may be used installed where the interface is documented and used primary as a callable.
Note there is a separate convention for buildin names: most buildin names are single words (or two words running together), with the CapWords convention used only for exception names and buildin constants.
At the very least, Python's official documentation and introduction do not mention the naming of the class, so you can name it whatever you want.
Also, if it is like the User class in the question, Python does not make it into a class, but uses tuple or dict, and UserFromDatabase is faster to make it into a module, so it does not use classes like Java, C#, Ruby.Therefore, I don't think Python explains the naming conventions for classes.
Among Pythons, you may want to study Django or SQLAlchemy for classes like questions.Also, isn't it a good idea to use Data Classes introduced in Python 3.7?Also, it may be a good idea to apply naming conventions such as Java, C#, Ruby, etc.
Based on the naming of object-oriented neighborhoods, it has UserFactory and delete functions, so I think it will be UserManager, but I think DBConnector is better.
This is because the member variables that the class maintains are about connecting DBs, and that is the significance of the class itself.
I don't make classes right away.First, create a new namespace and start writing functions.Then, create the class only if there is an inconvenience.
In the questioner example, clustering is meaningful to control the state of DB connections.I don't think what data is stored in DB is the essence of the class, and I think the definition of the conditions that the User type should meet should be defined within the User type.
For example, if you want to store something other than User data in a DB, for example, if you want to store Blog data and you name it UserManager, you will create a different BlogManager class.It is obvious that this will mass-produce classes that are not reusable.Every time you create a class, every time you try to store it in DB, I think it's important to think about whether you want to create a Manager class.
© 2024 OneMinuteCode. All rights reserved.