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
I know very little about design patterns out there. In fact i never worked with one yet, as i always went for raw coding. But i think its time to enrich my knowledge on design patterns out there. Specially i want to know more about Factory, Singleton & Strategy design patterns. I googled about them of course but I still not clear about their differences, how to implement them etc.
If anyone can suggest me some good document where i can read much more, that would be very much helpful.
Thanks in advance for helping.
https://sourcemaking.com/design_patterns is a very helpful website, with a lot of explanations and code samples, including PHP ones. I added very short summaries in my own words below. Disclaimer: because they summaries are very short, the may not be very accurate, but give you an idea on how the patterns compare.
Factory Method: https://sourcemaking.com/design_patterns/factory_method
In short: you have a separate class that is responsible for creating instances of a certain class. This is to make sure that a class is always constructed 'in the right way'.
Singleton Pattern: https://sourcemaking.com/design_patterns/singleton
In short: only one instance of a singleton class is possible, the class itself has a static class variable that stores the instance, and a static method that returns the stored instance, or create one if it is not yet created.
Strategy Pattern: https://sourcemaking.com/design_patterns/strategy
In short: if there are multiple ways to solve some problem, provide a set of classes that each contain one implementation to the problem and let the client decide which implementation to use.
Related
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 3 years ago.
Improve this question
I have a method that depends on many other classes like this
public function getProfileData(
ProfilesService $profile_service,
ContactInfoService $contact_info_service,
CoursesService $courses_service,
InterestsService $interests_service,
LanguagesService $languages_service,
PersonalInfoService $personal_info_service,
ProjectsService $projects_service,
SkillsService $skills_service,
AwardsService $awards_service,
EducationsService $education_service,
ExperiencesService $experiences_service,
TargetJobsService $target_jobs_service,
ProfileHiddenSectionsService $hidden_sections_service) { }
I read about dependency injection and I know that if you exceed 6-10 dependencies it leads you to a code smell.
But this getProfileData() method really need all of these dependencies so what is the best practice to solve this problem ?!
The code smell you are experiencing is called Constructor over-injection (and this particular variation is Method over-injection). As #Nkosi said in the comments, the source of this is a Single Responsibility Principle violation.
How to solve this problem, however, depends pretty much on the situation. Chapter 6 from the book Dependency Injection: Principles, Practices, and Patterns actually contains a very elaborate description of your options. In short, among other things, you can use the following refactorings:
Facade Services
Introduce Domain Events
Hide similar components behind a Composite
Extract cross-cutting concerns using Decorators
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
Read a lot of posts about storing sessions inside database but no one seems to provide proper information.Then i came across this post and i found it to be very helpful.
http://culttt.com/2013/02/04/how-to-save-php-sessions-to-a-database/
Now what i don't understand with these posts is that they are taking a class named Database which contain certain functions in order to make session class work i.e. to store sessions inside database.
Question : My question to you all is if it is possible please provide me with that database class even it means creating one own database class file.Just to make sure all the functions that the session class is looking inside database class are found and working.
Codepad:http://codepad.org/mtvT3XXB
That article you cite has horrible issues with wording (example: "...we instantiate a copy of the database class...", which is just plain nonsense). But the basic thing behind such "database" class simply is to keep things generic for the reader, which makes sense.
To interact with a database you need some routines for things like connection handling, query execution and preparation and the like. These routines are typically implemented as methods of a class. Such a class is what the author refers to. He does not name a specific one since they are more or less exchangeable.
You don't actually have to implement your own class, you can use one of those already provided. A short overview is given in the php documentation (which you should read!):
http://php.net/manual/en/set.mysqlinfo.php
I suggest you pick the mysqli connector and go through a few tutorials to learn what it does and how to use it.
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 6 years ago.
Improve this question
Just a quick question:
When looking to Controller.php:
What's the underlying coding convention for property-names? I always thought, that properties, which reference a object starts with a uppercase letter, whereas basic properties, referencing booleans/strings/ints, starts with a lowercase letter.
But, in Controller.php, there are:
public $request; // referencing an instance of a CakeRequest object
public $View; // referencing an instance of a View
So, where's the difference?
The general rule regarding variable and property casing is:
Normal variables should start with a lowercase letter, and should be written in camelBack in case of multiple words. Variables containing objects should start with a capital letter
As such your understanding is correct.
There are however some inconsistencies for/from:
Backwards-compatibility
Multiple developers, some more consistent than others
Mistakes =)
The reason they differ is changing opinion over time I guess. When CakePHP had relatively few objects internally it made sense to call them out with CamelCase names. However, over time we've added more objects, and in some cases like request wanted to avoid potential issues with userland code that may make Request. On top of these is the need to not break compatibility needlessly.
My current thinking is that framework internal objects, or non-userland objects will be camelBacked, while userland objects like Tables, Components, Tasks, Helpers etc are CamelCased.
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 attempting to create a login and registration system for my website, but I'm having trouble deciding on how functionality should be split up. For example should I have a User class that has login() and registration() functions, or should I have Login and Registration classes that contain a user object and the User simply contains data (id, username, etc...) without much functionality by itself? Do either of these seem like suitable OOP approaches, or am I way off base here?
EDIT:
Sorry that my question was so vague, I'll try to make it more specific. The User class that I currently have takes care of both logging in and registering. I've been told that each class should have one responsibility, so I'm not sure mixing those login and register into one class is good design. My question is when creating a class, specifically for a member system, is it better to separate functionality such as login, register and update into completely separate classes that have that have one purpose? Is one User class having a function for each of those purposes bad because it mixes too much functionality into one class?
Depending on your authorization system; both might be true or both might be false.
Short Answer: Select one of them and continue
If you want to write Good Code
Try to make it
Adaptable
Brief
Consistent
Correct
Extensible
Fast
Flexible
Generic
Modular
Reusable
Stable under changing requirements
If you are trying to make your code even better, first of all; I suggest you to write your contracts (a.k.a. interfaces). After writing your interfaces (one for your data provider maybe, and one for service provider); try to write one for your login & registration system. And then; you will find the answer I hope.
You can use any realization..
Just see realization of it in the top frameworks like Symfony, Zend, Yii, etc..
Or just use one of them. It is much better ;)
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 8 years ago.
Improve this question
I have read a lot about singletons, most people agree that they are bad practice and to avoid them, any way possible. Most people say this because it's hard to debug apps that use them.
Now, creating a simple CMS, I tried a few approaches and they seem to me the best choice.
Configuration data
That file is loaded on application start and I see no reason why I wouldn't use singleton pattern when calling config data throughout my application?
Request data
Request data should store all info from php server variables (POST, GET, COOKIE) so it can be used to read and write (e.g.cookies) data using singleton throughout the application.
Response buffer
I want to use response class (as singleton) that will hold all data that is rendered by my templates. So application can load all views render them one by one and store the echoed data in the response class, and at the end output entire document that is stored in response.
Questions for all examples:
A) Is that really bad practice, and why? I see no evil here.
B) Is there an alternative / better way?
Thanks!
Is that really bad practice, and why, as I see no evil here?
Design patterns are suggestions, not standards. You can use them, hate them, call them "anti-pattern" and do whatever you want but that will just be your opinion. The gang of four and any blogger out there express their opinion about it just like the way you do, and guess what? it doesn't really matter.
Instead of asking yourself if someone consider it a bad practice, ask yourself: "Do I consider it a bad practice?". If the answer is no then go for it.
I'd suggest you to read both sides (pro-singleton and against it) and make your own opinion about it, before taking this decision. But in the end there's no right answer, it's just a matter what you decide.
Is there an alternative(better) way?
Generally speaking I tend to use Dependency Injection more than Singleton where I can. But if there's no way I could use DI and Singleton is an option for me then I would surely go for it.
My suggestion is to learn the most important patterns and use whatever makes sense to you in that particular context.