Programmers often view object-oriented and functional programming as two completely different paradigms. As a result, some developers advocate for one them, pointing out the advantages of their favorite paradigm and criticizing the “opposing” one. However, I have rarely seen anyone comparing OOP with functional programming instead of contrasting them.
Dependency injection is one of the core ideas of object-oriented programming. Being an implementation of the Tell, don’t ask principle, it lowers coupling, makes software components more independent from each other, and, as a result, increases maintainability. There two ways the dependencies can be injected: using constructors (object composition) and using dependency injection containers.
Extension method is a special language feature introduced by Kotlin, Swift and other programming languages, which allows developers to add new methods to otherwise unchangeable classes. While at first it seems like a great idea, in reality it contradicts the core OOP concepts and ideas.
Creating a motivation for developers to make unit testing part of the software development process can be challenging. Although tests can be made a requirement, without clear understanding of the practical purpose of testing, developers might write tests only to pass the code review and keep the code coverage metrics high. However, if the project manager does not force the developers to write tests, who will? I believe that it is the project itself.
DAO (Data Access Object) is an abstraction that is used for CRUD database operations. In Java, DAO is typically implemented as an interface that declares the methods through which a programmer can interact with a database table. A DTO in the form of a POJO object is used by DAO as a data container, which passes data from a programmer to the database and vice-a-versa.
After analysing the criticism about DAO, I have decided to write out my personal thoughts on this subject. In this article I will create an implementation of DAO through the perspective of SQL-speaking objects.
The well-known disadvantages of getters have already been analyzed by a number of programmers. Yegor Bugayenko has gone even further and suggested a workaround. The pattern called Printer gives indirect access to the internal parts of an object by serializing it into one of the data formats, such XML or JSON and reading it’s content using an XML or a JSON reader. As a result, as Yegor states, the object stays intact and it’s encapsulation is not violated by getters. Although this approach might seem viable at first sight, I believe that it does not solve the fundamental problem of accessor methods.
Most people who start a blog face the questions that are common for newcomers: How to make it popular? What blogging platform to choose? And, in some cases, how make money from it? However, these questions have no exact answers, just as there are no magic bullets for blogging. The moment you realize that, you change your strategy and start looking for successful bloggers and try to learn from their experience. One of such bloggers is Yegor Bugayenko the author of the “256 Bloghacks”.
The disadvantages of Object-Relational Mapping (ORM) have already been discussed by a number of developers. The main argument against ORM is that it leads to the creation of DTOs, which encapsulate data, rather than behavior. If one decides to accept this claim, what alternative solutions does he have? One of them is a SQL-Speaking object.
