Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
design patterns are also kind of a common ground when developing in team, from the high level architecture to the mere optimisation of algorithms. They make other ppl spot the logics in seconds instead of digging for hours deep inside obscure code. time saved that can be spent more productively.
And often they're full of best practices in order to avoid certain typical flaws that may emerge in the future.
They're shared knowledge from a collective experience.
They must be adapted to every specific situation, stack, problem, project and team ofc, what works here may be not the best call there, but to figure this out is our job. -
Design patterns are not much else than well thought-out, clean code. With enough experience you'll automatically use design patterns you didn't even know existed because it's just common sense to implement certain things in certain ways.
So do what you want, but you should know that in the long run it might save you a lot more time and effort to learn design patterns now before you learn them the hard way.
And once you know how to apply design patterns you'll realize they aren't nearly as restrictive as you are describing. They're more restrictive than chaotic spaghetti code, but that's the point. -
@SukMikeHok on the other hand, you can use clean, well-structured code on Github when applying for jobs, which won't work with hacky shit. Double so in case you drop college.
-
@SukMikeHok I don't understand how design patterns relate to where you put things. Maybe you are still Junior and haven't seen enough code. But eventually you will see in many programs you are essentially solving the same problem/issue again and again.
I think design patterns are more applicable for large systems with many parts that need to be maintainable and flexible. And help you analyze big problems and break them down in to smaller components and parts.
is it ok if im the only person who codes an android app and i code it by my own free will and skills?
meaning im not following any design pattern while doing so.
i dont like following design pattern because it narrows down my freedom of writing code the way i want to write it.
its like, imagine, you have a strict schedule or a dad who says at:
5:59am: get up
7:15am: study
9:01am: eat breakfast
11:00am: go to college
3:07pm: eat lunch
5:14pm: come home
8:02pm: eat dinner
9:00pm: brush your teeth
10:58pm: go to bed
11:59pm: you must sleep before midnight
IMAGINE THAT. be honest, could you actually follow this schedule in its exact hour and minute as it was written down for the rest of your life every day, no exceptions?
if you're a sane person, you would answer - no, of fcking course not.
life is much more broader and dynamic than following a static pattern every day forever.
so is not following a static design pattern while coding an app.
rant