Like MVC, MVVM, MVP.
How does it apply to
- Server-side only?
- Frontend only?
- Fullstack?
- Desktop app development?
- Mobile development?
- Starting a project from scratch?
- Continuing someone-else's project? Or forking a project?
- Working with a team?
Like MVC, MVVM, MVP.
How does it apply to
For further actions, you may consider blocking this person and/or reporting abuse
The answer is simple.
When you begin coding, you shouldn't worry about those. At all.
And then, when you write sufficiently complex projects, your code will become a horrible mess... and then you will understand. :)
on point :))
lol. That's the most efficient answer.
I would add to try to add new features or functionalities to an app that you've developed 1 or 2 months ago. You will see how complex could be to understand your own code and why you took those decissions.
There's a few things - but first I'd say this:
That out of the way - here's why they are useful/important:
Xand it just happens. Magic! ✨ Examples are auto-routing and resolution of views in MVC. Gone are the days of mapping - most frameworks do it all automagically.You are actually quite clear. Thank you.
MVC, MVVM, MVP are just a very small part of software architecture that applies to web applications with integrated backend/frontend, where Controller is the isolated backend task (like
GetAllCustomers), Model is representation of data (coming probably from some sort of database) and View is the presentation layer.In general software architecture is trying to make the code logically structured, isolated, easy to extend and maintain.
This results in code that does not repeat (you don't have to write and maintain the same logic in multiple places, where forgetting to update function that does something important in all places all over the project results in inconsistent or erratic behavior of the application).
It also tries to isolate and structure your code into domains where e.g. class
CustomerRepositoryin a fileCustomerRepository.javadoes only Customer related tasks so it is easy to identify within your project what goes where and where to search for it. This becomes more important once you start usingInversion of Controlof some sort, likeDependency Injectionwhere the dependencies are loose (they might be figured out at runtime not at compile time).It also tries to form some sort of abstractions (for the same reasons mentioned above, where your isolated domain responsible pieces of code does not need to hardly depend on specific implementations). This becomes very useful during testing or running different environments (test, staging, production). You probably don't want your developers to upload files to your production storage from their development machines every time they run the code the same way you don't want to test some features together, like calling an API that deletes data from the database. For this reasons you'll impement
Interfacesthat just define how your object should look like and behave but you develop multiple implementations - one for production that does what it should in production, one for unit tests that deletes data from local SQLite database and returns the success result or just mock/fake that just returnstruebecause your test is focused on running the API call, validate credentials, authorization, input parameters and produce valid response, but not focused on whether you can delete data from a database which you'd need to prepopulate before each test as response from the database trying to delete data from empty table would mess your test results.Another goal is to make code extensible. Here again
Interfacesreally help as you can define an interface calledIVehiclethat implements typical vehicle features (length, weight, person capacity, etc.) and has typical properties. This can be used in places where you don't care what vehicle it is, like implementing aHighwayclass where any vehicle can ride on it. Then you can extend theIVehiclewithIPersonalVehicle,IBus,ILorrywhich are based onIVehiclebut extend it with different properties and functions (e.g.bool isLongVehicle,uint TrailerCountetc.) which you can use while implementing e.g. a highway toll gate where you have specific gates for specific vehicles and you cannot passILorryobject type intoPersonalVehicleTollGate()function because the parameter type does not match but still you did not have to implement basic functions of theILorryobject implementation over again because they are inherited from genericIVehicleinterface. As you now have anPersonalVehicleTollGate()function andLorryTollGate()you don't have to write a big switch case orif (vehicle.type == Lorry)within your function. It also helps your unit tests to not depend on specific implementations but rather generic ones or to provide fakes/mocks as mentioned before.Interfaces also allow you to swap implementations, e.g. you develop an app that stores files in Google Drive by implementing Google's REST API calls in appropriate places in your application. However you soon realize that there is a limitation of some sort and you need to swap for S3 storage. Ideally you'd implement an
IRemoteStorageinterface at the beginning with methods likeSave(),Read(),Delete(),Search()etc. and implementclass GoogleDriveStorage extends IRemoteStoragethat abstracts the implementation. Then when you need to change from Google to S3 provider you need to develop another implementation based on the interface and just swap them in the application initialization where you register your newAmazonS3Storageas an implementation ofIRemoteStorageinterface in Dependency Injection container instead ofGoogleDriveStorage.The rest makes sure the application can be easily developed and maintained by multiple people at the same time.
Software architecture is nothing without correct algorithms and data structure to solve business problem.
What you need first is not software architecture, it's your algorithm.
Then comes your data structure.
Then you might need a SQL database to keep your data consistent.
The last one you need "might" be a simple software architecture, like MVC. Most of framework out there can help you with that.
To me, principle is more important than software architecture. Use what best to your use case.
The problem with that approach lies is what is often seen as the succinct definition of architecture: that which is hard to change afterwards. That doesn't mean that you need to think about architecture from the very beginning, but as soon as you have a serious project, that project will need an architecture.
Ehh. It just makes your life easier.
Think of it as a shelf or wardrobe.
You can dump everything inside it. Nothing wrong with that, but only you can find a particular item, and it's taxing.
If, however, things are neatly ordered, then you can find an item easily, and others can do the same.
I know why, It applies to various reasons and some of them that you asked in your question. These are my two cents.
When you have domain classes and services separately, you can easily test and diagnose them out if the need arises. Rather than reading the whole chunk of code, you could just simply enter the service file and debug some functions to save time.
As the code grows, a situation may arise that you need to deploy multiple systems dedicated to one and only one thing.
For example background jobs that take a long time to run can be deployed separately and APIs Project can be deployed separately so that both do not eat up resources of each other.
While working in teams, Its a good practice to use VCS and the team will be happier if they have to work less on resolve conflicts on others code.
I hope others add their bit too.
By following standard pattern/architecture, you're sacrificing short-term dev time for the long-term.
Usually you create more classes or code to solve what seems to be simple at first. For junior, trick/hacked solutions always look better if they don't see the long-term benefit.
If design pattern is used efficiently, future you or your teammate can easily understand the code / identify issue, from a higher level rather than go through the code details.
Actually, I'd look for benefit of
You will naturally feel the need for soft arch as your projects start to grow and you become unable to control and maintain them unless you structure them properly 😄
Start studying arch calmly now, and don't rush. The need and frustration will point you in the right direction 😉
You will naturally go through many processes of learning... functions, oop, back to functions, back to oop, test-driven, test forgetting, back to testing, circular imports, CI, 'omg what was that pattern again?', over-kill implementations, etc.
enjoy the road, it's beautiful, I definitively love it ❤️
Is the said "anti design" an absolute indicator, that the project will fail, or just in some ways?
@patarapolw
Mostly, in software design you'd hear about
anti-patterns(I haven't seen anyone using the termanti-design). The things you've described(MVC, MVVM etc..) are actually software architectural patterns, simplydesign patterns. Design patterns have been invented to solve common software problems, but of course, they are not universal solutions(they have pros/cons and trade-off). And anti-pattern means such design pattern, that creates much more of a problem rather being a solution, though at first it seems to be a great solution. Such an example issingleton pattern. Actually, it's still encouraged in many cases, but single pattern causes a lot of problem in terms of code maintenance and testing.Of course, you'd hear about software architectures too, such as
monolithic architecture,microservices,service oriented achitecture i.e. soa(actuallymicroservicesis a kind ofsoa) etc...It's always good to learn design patterns and software architectures...but take your time to understand and apply those :)...
If you don't have an architecture in your project, you won't be able to improve your code or refactor that easily and nobody can contribute to the project easily.
That maybe a point; but how do I get started?
For example, Express.js (although I love Fastify much more, and couples of microframeworks in other languages); or Vue / Nuxt for the frontend (I never get accustomed to React / Next / Preact).
Furthermore, can I even expect contributors in the first place? I feel that fame / usefulness-to-others is hard to come by...
If you're learning to code at school/university etc, you will eventually have to do a group project. If you are starting a job, you will definitely either have to work with another developer, or work on an existing codebase..!
Apparently, my course is Informatics, not really computer science. And there are a lot of other topics to focus on, anyway.
Over time, when you learn to code by writing smaller scripts, programs, tools...etc you would realize how the operating system manages to run your program. You simply cannot write a program that does what you wish for unless you think like a computing resource. It pushes you to dig more about what you just discover. For example, it could be about the limitations associated with Memory, OS, I/O Buffers, or other physical resource limitations that you never thought existed. As a computer programmer, you are always bounded by such limitations.
Dealing with limitations is not an easy task, it takes time to think, implement, and validate the solution. Simple or Complex projects, both are bound to face limitations that we have seen in the example mentioned. When a system reaches it's limit the performance takes a severe hit.
Over the years, people (software engineers, computer scientists...etc) in the industry have identified methods to utilize these limited computing resources in an efficient way and solve problems that surface very often today. Be it in Operating Systems, Web, Device Drivers...etc the underlying principle or patterns are proven to work gracefully with such sorts of limitations.
When you understand the principle and apply it to the problem at hand you would realize that it easily solves some of the use cases that were not possible or hard to accomplish with your nascent naive approach. Of course, your solution will mature from a naive approach but it will happen overtime.