Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm just wondering, I'm new to this pattern subject, I started like couple of weeks ago but my main problem is, when I start writing small applications (for self purposes) I can't think where to put any pattern to use, maybe it's my thinking structure that needs to be tweaked ?
If I start a new project, how would I know if I need to use a pattern ? what questions do I ask myself ? what steps do I take before writing the actual code ?
Look at the Delphi VCL...it's basically took the Design Patterns and ran with them...
Forms are Composite Patterns.
Datasets use the Iterator Pattern.
Screen and Application are Singleton Patterns.
Components use lots of
different Patterns, the Chain of Responsibility, Decorator, Facade
to name a few...
Patterns are ways to organize your program and objects in lightly coupled objects that have jobs that you do over and over again...
Design patterns are just ways to approach solutions to common problems. As you internalize the patterns and as you understand the problem better you will sometimes see that the problem (or part of the problem) you are solving is addressed by a particular pattern.
That's when you use it. When you see it solving your problem.
Design patterns are reusable solutions for common problems.
The principles of Software Engineering cites the reusability of codes, when you use a design pattern you are using a concept previously tested that went trough several validations and is less prone to an design error than if you design your own model.
So first, you have to know the existing design patterns and what they're intended to solution. When you face a common problem you may remember the design patterns you previously studied and use them to solve the situation you're facing at the moment.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am going to start a new application in iOS and there are multiple architectures available in iOS i.e Viper,MVVM,MVP and MVC.
I have search google but didn't find any specific use of these architectures.
Can anyone please guide me that when and which architecture should be used and which is more beneficial?
I will try to put my answer in short:
MVC: This is the basic architecture you will find most of the people use. Without knowing this, don't go forward as it's wasting time doing so. But this architecture no one is interested in the current market as it has few drawbacks. When comes to unit testing people find it difficult. So they started moving on. One good thing about this architecture is your development is super fast.
VIPER: which became very popular these days for its separation of data, design, controller logic. For unit testing, it will be very nice. But understanding and putting efforts in this are more. If you fully understand this one, I advise you to go.
MVP: People who understand MVC, can easily go with this MVP. As there are not many changes involved in this from MVC. Presentation logic will be separated out. If you want to build good architecture, not the basic one go for this.
MVVM: It also requires good efforts from you. Don't go until you understood. Again very good separation of model, View, ViewModel.
Now it's your choice to get onboard. As all of us know, how important an architecture is for an app, don't take fast decisions here. Take your own time and conclude based on the time you have in your hands, the need for proper architecture.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
So, what most comfortable and useful for developer? A similar question was already 4 years ago, and many things could change.
http://activeadmin.info/
https://github.com/sferik/rails_admin
or maybe Typus https://github.com/typus/typus???
Disclaimer: this is only opinion. This kind of question can have no 'correct' answer.
I use Rails Admin a lot on my current main project. It has advantages and disadvantages.
Advantages:
It handles things like nested forms for ActiveRecord relationships out of the box.
Disadvantages:
Adding features or custom behaviour is quite difficult and documentation is over-complex and fragmented.
Putting the DSL for CMS behaviour in the models is not great for code separation.
The default style is a little outdated.
The DSL itself is over-complex, badly documented and prone to code bloat and duplication.
The use of PJAX for page updates can complicate any JS you wish to add to the page. (If you're not careful your code will be run multiple times, or not at all, for a single page.)
The default mechanism for saving content items is incompatible with a database that uses referential integrity. This is a very bad thing. (I ended up patching this code.)
I haven't used ActiveAdmin as much, but when I have I noticed the following things:
Out-of-the-box, you have to roll more of your own features when it comes to things like nested forms for relationships. (This may have changed over time.)
It looks lovely.
The DSL is neatly separated from the model code and feels more logical.
Adding your own features is a lot easier with less code.
Adding JS is pretty trivial.
I don't know if Active Admin is better for referential integrity, but if this interests you let me know in comments and I'll set up a couple of trial projects to show you what I mean.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
This may be a generic question but still i need suggestion/guidance on which design pattern or architecture to follow for developing this app.
The app is for premium users(for iPhone) on airport and will be able to access the internet at higher speed and on multiple devices simultaneously.
I'm planning to go for Singleton,Factory,MVC patterns and client-server architecture for the app.
What-all things do i need to re-think and then design the app or are above patterns sufficient to go ahead ?
thanks
It seems bizarre to come up with a list of patterns to use before you look at what your app is actually going to do. This is not how you use design patterns.
The way to use patterns: When you have a problem, and you think about how to solve it, you try to find out whether your problem fits a well-known pattern and adapt that pattern to your problem. Or you figure out that it doesn't fit any well-known pattern, and then you solve the problem without using any pattern.
This is like going to a shop buying blue and yellow paint, and then deciding what parts of your home you want to paint. You do it the other way round. You decide what needs painting, then you decide what would be a nice colour, then you buy the colour. You don't buy the paint first. You don't decide on design patterns first.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am new to grails. One thing I have noticed in the codebase of my current project is that the domain classes and the controller classes share the same package. So, you have something like this:
grails-app/controllers/foo/BarController.groovy
grails-app/domain/foo/Bar.groovy
So, is this a common practice? What are pros and cons of this? Thank you very much.
I think it's ok to use the same package for domain objects and controllers.
There is a practice called Package by Feature, which argues that grouping classes by what kind of component they are or what layer they are in is not as effective as grouping things together that contribute toward implementing the same functionality. When I work on projects packaged by layer I do a lot of hunting around going back and forth, grouping by feature would reduce that.
Usually domain objects have very little private about them. Also privacy in Groovy classes is nonexistent anyway.
This is how "convention" works over "configuration" in Grails. This is a common practice. I haven't found a demerit using it this way.
Normally, when you create-domain-class or create-controller even the tests are added in the same package as the domain class/controller respectively.
Best example of convention I can cite is when you use
grails generate-all yourPackage.Domain
Stumbled upon a similar post related to Grails where exactly the package by feature aspect as mentioned by Nathan is explained. Hope that helps.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
You can find thousands of questions out there about how you develop software and which methodology is the best one. But mainly these are targeting medium to large teams, with people having different roles and responsibilities.
What I'm interested in is what methodology are you using for your one-man-shows? What steps are you doing, what documents are you creating to get the things you want to develop clear and document it well, to share it with the community?
Especially, I’m interested in the following questions:
_Are you using a structured approach even you’re developing on your own or no at all?
_What phases are you using?
_Which documents are you writing before and after coding?
And if you have “your” standardized approach, can you share templates which you are using?
Thanks in advance,
cheers
Gerry
Personally I think it is a matter of making decisions when it comes to the development process (solo). In my case I wouldn't recommend setting up a massive development process but I would pick elements which prevent problems that I have earlier had. My approach for small applications (in the right order):
Always write down what you are going to make and what you are not going to make (define a scope) - Think of functional requirements (Functional Design)
(OO only) Make a class diagram that displays relations between classes. (Technical Design - Sequence diagrams, while usefull, take up massive amounts of time to make)
Write your program according to what you have just written down (or part of it).
Refactor and redesign your application (once in every X hours, write this one down)
Repeat step 3 to 4 until the result is what you wrote in the Functional Design.
Walk through every corner of your application to find every single path and write this down in a testdocument. Identify possible problems in the paths and test them.
When it comes to big applications however (or assignments for someone else) I prefer using the "medium to large teams" approach. Which almost brings a guarantee that you will not be meeting most problems.