Answer the question
In order to leave comments, you need to log in
Online store and OOP?
There is a self-written engine for an online store (perl).
It was written from scratch, developed under the influence of ideas that gradually appeared and took shape, as a result, the code became large and poorly organized.
Difficult to maintain and supplement.
At the same time, the engine is completely procedural, because. I didn't know much about objects.
Now there is a need to seriously rework the structure, and I'm looking towards objects, since OOP, as far as I understand, is just designed to split large tasks into small subtasks in order to make them easier to maintain and supplement.
But since I'm not familiar with objects, I can't figure out how to use them in this case.
What can be objects in the online store engine?
Answer the question
In order to leave comments, you need to log in
As practice shows, in OOP you can pile up such things that you will then howl with support and expansion.
In addition to OOP itself, it would be nice for you to get acquainted with patterns. Skillful use of them gives rise to a flexible architecture that can be easily expanded, supplemented with functionality and edited.
The best book on patterns is "Object Oriented Design Techniques" by the Gang of Four. But for a person who is just starting to get acquainted with OOP, it will be quite difficult.
For beginners, I would recommend reading Design Patterns by Eric Freeman and Elizabeth Freeman. The book is written in the head first style, with lots of pictures and examples. Just in the course of reading, learn to "see" the world around you through the prism of objects with their methods and properties.
Download some project written in OOP style and study for a while. And objects can be just about anything, which can have many methods or it is required to store internal state.
For example, if you have methods like user_create, user_save, user_delete, etc, then it's natural to organize this into one class.
Divide the system into components based on the task. Let's say, if we proceed from the MVC pattern, there should be objects for working with the base (Order, Client, etc.), a class dealing with the representative part and controllers (OrderController (Moreover, for the user part, you can inherit from Controller and for the admin panel AdminController), ClientController , CatalogController). The store can be roughly divided into at least a catalog and a shopping cart. There is also delivery, payment, etc. All these parts can be divided into modules (in the case of delivery and payment, these will be controllers and models) ...
Well, that's about it. You just need to break everything into these very subtasks. And you need to think about how to break it down so that changes in one component do not lead to the need to change something else ...
At one time, I began to study OOP from this book:
Grady Booch: Object-Oriented Analysis and Design
This is exactly what you need now. Then you will see for yourself what and how you will need to change in your project.
For the web, the procedural style is quite appropriate. However, I have almost never seen non-procedural style web applications, even though there are classes there, because these classes basically describe stateless objects like controllers and services, in which 95% of the logic. And writing the create_order method inside the OrderService class or writing the create_order procedure inside the ordering module does not make much architectural difference. Read about MVC. It can also be divided into three layers with a procedural approach. Although this division is attributed to OOP, it can be found in any paradigm.
As for the idea of making save/create/update/delete methods for the user model, these are the rare examples of using OOP that are still used. This solution is called ActiveRecord. If you do not have an ORM library, then I advise you not to deviate from the DAO procedural pattern (read about it). Remember, the procedural programming you're using is not what the books say, since perl is at least a dynamic language.
Yes, I forgot. The most relevant book on OOP design that I have come across is Evans' Domain Driven Design. I read Buch and I got the impression that he described very poorly how all this can be applied in practice, in other words, he did not describe the entire development methodology, but considers everything using some hypothetical examples.
We once had a store, pearl + OOP, so everything written below is subjective experience and a description of a specific implementation, and not a strict dogma.
First, everything is very well and usefully broken down into objects. Some of the objects can be mentally “touched” – these include user objects, product objects, a basket object with sub-objects-positions (product + quantity), an order object with positions (product + quantity + fixed prices) and a lot of other dregs. Some of the objects are already more difficult to touch, but their introduction also gives a profit due to polymorphism and inheritance - in this category, for example, we have objects responsible for implementing various delivery and payment methods. As usual, it turned out to be the most interesting and not too simple to link all this into a single system. Many objects depend on each other in both directions, but nevertheless, it was possible to avoid cyclic relationships.
What can objects give you? The most obvious example is, of course, a product. Suppose we have two tables - with books and disks - and ActiveRecord classes attached to them. We begin to determine what we need from the product. By and large, this is the price (with currency, if necessary) and the name. The rest is less interesting and may come in handy in particular cases. For example, to calculate the cost of postal delivery, information about weight is useful, and for all sorts of marketing tricks, the “price with a discount” field (for the beauty of numbers, it is more convenient not to set this field as a percentage). We define methods that will return this information. Let's say you want to make sets of several products. We are starting a new class, for which you can define your name and price with a discount, the price without a discount is summed up for the products included in the kit. Well and so on on the product page, it can be displayed as you like and there can be as many fields as you like, while the “basket” sees its own set of fields, and only that. By and large, if we already have a system that can read books, attaching sets to it is the price of writing one small class with a couple of required fields.
Delivery also has a name, cost, arbitrarily depends on the contents of the basket, delivery address, may be valid or invalid in these conditions (as a rule, courier delivery to Petropavlovsk-Kamchatsky is not possible). Similarly, with payment, but it also depends on the delivery (you cannot pay the courier with cash on delivery).
The basket includes information about the goods, user, delivery and payment. An order is painfully similar to a basket, but all information that can change is stored separately in it. For example, prices, addresses may change.
If you start to implement, start simple - with goods and baskets. Think about what a basket is, what it includes besides goods, how many baskets a user can have, whether an “anonymous” basket is possible. The first two questions will let you decide what fields and methods the object should have, the second two - how to get a specific basket object when you want to show it on the page. Implement what you have done, without deliveries and payments yet, but so that it looks “like everyone else” on the screen. Add the rest gradually, look for places where you can make several different implementations of something with the same interface - perhaps this can be separated into a separate object. But don’t crumble unless necessary, it will be difficult to assemble into one whole :)
Something like that. Good luck!
Oh, Perl is alive! Pleases :)
Objects in the store can be everything, from the catalog controller, to models working with the base.
By objects: Catalog, Catalog elements (product), Cart (connection with goods), User > Administrator > Manager, Payment associated with the completed cart.
And if you still stick with Perl, check out Moose, Mojolicious.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question