Can anyone explain how can I distinguish between decorator, abstract factory and factory method patterns with real examples please. Precisely, I need to understand when I should use decorator and abstract factory and factory method.
Design Patterns are not so easy to explain by just text. I'd advise you to watch this playlist of Derek Banas: https://www.youtube.com/playlist?list=PLF206E906175C7E07
I learned the patterns from him, and I still remember his tutorials when programming. His examples were really clear to me, and they will to you.
Related
I was asked this question in one of my interviews and still dont have answer to it. If by abstraction we only mean , you not able to instantiate object(as applicable for interfaces and abstract classes), so having a private constructor is the answer?
Abstraction is explained in varied ways all over internet . Even using System.out.println is abstraction as we dont know detail behind it .
Using factory classes is also abstraction as we dont know which subclass will be instantiated.
Calling any method within an API is also abstraction.
I am actually confused now, as to what the interviewer wanted as answer.
Abstraction is all about hiding implementation, like how the gas pedal to a car abstracts you from the various complexities in making a car go.
A simple way of doing it is to just use private members. GetActiveServers() could call no private methods, or 5 private methods. That doesn't really matter when we're using it, so long as it works efficiently as needed.
I think he was trying to trick you because of the abstract keyword sort've means something different from abstraction, but it's not entirely unrelated.
I am seraching information about to test methods and Moq it's a good alternative, but it can't mock static methods.
However, is a question in this forums, I read that static methods are more efficients (consume less resources) than the non static method. Also, if a method does not use particular data of the object, it's a better option the static method. The question was in this post.
But if the method is static I can't mock the method, so it's seems that in some cases must choose between to be able to test the method or the performance of the static method.
There are some free alternative to moq to test static methods?
Thanks so much.
I do not know of a framework that can mock static methods because I do not believe it's possible except through something like assembly injection (i.e. emulate the assembly, namespace, and class so the method resolves to the injected symbol).
However, I need to ask, do you have code that needs to be so performant that sensitive to the minimal costs from calling an instance method? I highly doubt that's the case, and if it is, you shouldn't be using an environment that can pause your code for many milliseconds to perform a garbage collection. If that is the case, I'd love to know what kind of software you're writing :)
So if your code is not being used in high-frequency trading software, then consider if you'd rather have tested code or extremely marginally more performant code. This reeks to me of premature optimization...
I'm modeling a web application, which has some HTML pages, javascript files and 6 servlets.
Right now I have all the servlets in separate classes, but they all share the same methods (doPost, doGet, processRequest, with different implementations) and all of them have the <servlet> stereotype.
I was wondering if there is a way to represent all of them with one class. I'm going to do a text to describe the diagram, so maybe I can explain what that class represents.
As all the methods you cite (doPost, doGet, processRequest) seem to be inherited from Java's HttpServlet, you may as well represent all the implementations with their common parent class HttpServlet.
If the design goes ahead of implementation, I would suggest you create an interface with the common methods(doPost, doGet, processRequest); then different classes implement the same interface. You can optionally introduce an class with default implementation of the interface and let your classes generalize from this class.
If the implementation was already there, to be honest, it is not well designed. A refactor will be much better.
I've been reading Microsoft's Prism Documentation and it has a lengthy discussion of the MVVM framework. Both the section discussing the Model and the one discussing the ViewModel talk about the View binding to the properties declared in each. Is this correct? Everything I read up until this made it seem like the ViewModel was the intended binding source, and the Model was more of the business logic. Any clarification would be appreciated.
Almost all of the time you will be binding to ViewModels, which will wrap Models and add convenience functionality that has to do with your UI (and which would hardly belong to the Models directly). Sometimes not much convenience is required and you might end up binding to Models directly (although personally I choose to never do this).
The documentation is indeed a bit unclear on this as you mention, but in a nutshell your grasp of the situation is spot on.
Generally speaking, creating a fluid API is something that makes all programmers happy; Both for the creators who write the interface, and the consumers who program against it. Looking beyond conventions, why is it that we prefix all our getters with the word "get". Omitting it usually results in a more fluid, easy to read set of instructions, which ultimately leads to happiness (however small or passive). Consider this very simple example. (pseudo code)
Conventional:
person = new Person("Joey")
person.getName().toLower().print()
Alternative:
person = new Person("Joey")
person.name().toLower().print()
Of course this only applies to languages where getters/setters are the norm, but is not directed at any specific language. Were these conventions developed around technical limitations (disambiguation), or simply through the pursuit of a more explicit, intentional feeling type of interface, or perhaps this is just a case of trickle a down norm. What are your thoughts? And how would simple changes to these conventions impact your happiness / daily attitudes towards your craft (however minimal).
Thanks.
Because, in languages without Properties, name() is a function. Without some more information though, it's not necessarily specific about what it's doing (or what it's going to return).
Functions/Methods are also supposed to be Verbs because they are performing some action. name() obviously doesn't fit the bill because it tells you nothing about what action it is performing.
getName() lets you know without a doubt that the method is going to return a name.
In languages with Properties, the fact that something is a Property expresses the same meaning as having get or set attached to it. It merely makes things look a little neater.
The best answer I have ever heard for using the get/set prefixes is as such:
If you didn't use them, both the accessor and mutator (getter and setter) would have the same name; thus, they would be overloaded. Generally, you should only overload a method when each implementation of the method performs a similar function (but with different inputs).
In this case, you would have two methods with the same name that peformed very different functions, and that could be confusing to users of the API.
I always appreciate consistent get/set prefixing when working with a new API and its documentation. The automatic grouping of getters and setters when all functions are listed in their alphabetical order greatly helps to distinguish between simple data access and advanced functinality.
The same is true when using intellisense/auto completion within the IDE.
What about the case where a property is named after an verb?
object.action()
Does this get the type of action to be performed, or execute the action... Adding get/set/do removes the ambiguity which is always a good thing...
object.getAction()
object.setAction(action)
object.doAction()
In school we were taught to use get to distinguish methods from data structures. I never understood why the parens wouldn't be a tipoff. I'm of the personal opinion that overuse of get/set methods can be a horrendous time waster, and it's a phase I see a lot of object oriented programmers go through soon after they start.
I may not write much Objective-C, but since I learned it I've really come to love it's conventions. The very thing you are asking about is addressed by the language.
Here's a Smalltalk answer which I like most. One has to know a few rules about Smalltalk BTW.
fields are only accessible in the they are defined.If you dont write "accessors" you won't be able to do anything with them.
The convention there is having a Variable (let's anme it instVar1.
then you write a function instVar1 which just returns instVar1 and instVar: which sets
the value.
I like this convention much more than anything else. If you see a : somewhere you can bet it's some "setter" in one or the other way.
Custom.
Plus, in C++, if you return a reference, that provides potential information leakage into the class itself.