0
0
0xE02013-02-04 12:25:30
Java
0xE0, 2013-02-04 12:25:30

Designing Java applications for dummies?

Advise literature for a beginner to study a normal PL (before that, he wrote only in 1C).
I am familiar with the basics of OOP, learning the syntax of the language is also a bad thing, not tricky.
I am currently interested in what exactly where to place, that is, a simple example:
I am writing a program that reads mail and writes it to the database, to work with the database I write a separate class with methods connect, insert, update, delete. But where to create it (class object)? In the main class, or is it more correct to create a separate class for this, and leave only its creation in main? And now in main such noodles turn out.
In general, we are primarily interested in the correct planning of the application architecture, in which cases it is necessary to create an interface, a class, and in which cases methods can be dispensed with.
I understand that the question is stupid in essence, therefore, if necessary, I will answer clarifying questions.

Answer the question

In order to leave comments, you need to log in

5 answer(s)
R
randoom, 2013-02-04
@randoom

Read "Philosophy of Java" a couple of times

D
dshvechikov, 2013-02-04
@dshvechikov

The usual practice, as for me, is that there are essences.
For this entity, there is a dao layer (repositories, storage is not important), where the work with the base (crud) takes place directly, of course, through the interface.
There is also a service layer, where there are various kinds of checks for null, some other logic and method calls from dao. Of course, the interface for the service
Different parts of the logic interact with each other through such services. Those. if you want to get a Book by id, you make a call to bookService.findById(id); and the logic inside this service already makes various kinds of checks for the validity of the same id and pulls the corresponding table in the database

J
jarvis, 2013-02-04
@jarvis

We create the DataBaseConnection class, in it we implement your connect, insert, update, delete methods. Then, in the main class or in another class, we create an instance of this class:

DataBaseConnection MySuperCoolDatabase = new  DataBaseConnection(......);
// а затем используем методы
MySuperCoolDatabase.insert(...);
MySuperCoolDatabase.delete(...); // и т.д

Interfaces describe only the behavior of an entity (what an object that implements an interface can do through its methods, what events it can generate, and through what properties it can talk about itself)

S
SergeyGrigorev, 2013-02-04
@SergeyGrigorev

To work with a database, see an example implementation using the MyBatis framework. www.mybatis.org/core/getting-started.html
I really like the architecture in which it works with database objects. Everything is quite logical and clear.
Here sqlSessionFactory is used, which is responsible for connecting to the database. Mappers are used to access specific entities, such as BlogMapper. These mappers allow you to read, modify, and delete Blog objects from the database.
sqlSessionFactory is created at application startup and stored, for example, in a Singleton field.

D
dborovikov, 2013-02-04
@dborovikov

> But where to create it (class object)? In the main class, or is it more correct to create a separate class for this, and leave only its creation in main?
Think very well. First of all, read about Dependency Injection. The bottom line is that each object should not create other application objects on its own, but should expect to receive it from the outside through a constructor or setter. Well, then you can either create an auxiliary ApplicationContext class, where you create all instances and pass objects to each other, or do it as it is done almost everywhere: through the description in spring xml.
> In general, the correct planning of the application architecture is primarily of interest, in which cases it is necessary to create an interface, a class, and in which cases methods can be dispensed with.
Each class should have as much functionally coupled logic as possible. Working with the database is one class, business logic is in another, and so on. You see some specificity that is different from everything else - take it out. As for interfaces. You can start by making an interface for each class. Like FooService + FooServiceImpl.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question