As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Would I be correct in thinking that an interface has 3 main benefits.
A blueprint to what must be created (I have also heard others refer to it as a contract).
Polymorphism.
Unlike inheritance (which IMO has many similarities) you can have many interfaces
Are there any other plus or minus points and does anyone not agree with my 3 points?
The "blueprint" metaphor works better for classes than for interfaces, but the "contract" metaphor is pretty accurate. An interface specifies what other classes can expect in terms of public methods, without saying anything about the underlying implementation. Where inheritance between classes tends to consist of is-a relationships, interfaces can be thought of as works-as-a relationships, though I don't think the latter term is in common use.
I would add that the use of interfaces goes some way to creating self-documenting code. For example, the interfaces that your class implements describes the functionality the class supports. So, you end up with code that looks like:
if (someClass is ISearchable)
{
someClass.Search();
}
Two objects with the same Interface do not need to be otherwise related.
So you could have
- Flower
- Truck
- Dinosaur
all having the same interface
- IColor
even though they are completely different objects.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
When I'm implementing design patterns, should I keep terms like "strategy", "visitor", "facade" or could I fit these names to the context of my application ? What is the best practice ?
You should fit these names to the context of the application. It will make it easier for the people reading your code. You can add the patterns in your documentation.
I think you should always keep some reference to the pattern in your naming where it makes it meaningful and descriptive.
Patterns are a means of communication. If I come across code that is an XyzVisitor, I know that the visitor pattern has been used. With nothing else, the name has conveyed a whole stack of information on how the code works (or should work).
That said, sometimes it would just be a bit odd. Eg. DatabaseSingleton. Whereas AccountRefreshCommand fits quite nicely.
Depends on which pattern you're using, Some pattern names may be mixed with class names, e.g. I use
class LogFactory
class StudentsAdapter
for factory and adapter patterns, but
Engine.Instance
for singleton.
Depends on whether you are happy renaming the class in the event of using a different pattern, for me it would smack too much of hungarian notation difficulties.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The use of design patterns in programming is wide spread across many programming languages. A number of examples are the factory, or singleton design pattern. Many of these patterns use object orientation to create abstraction and encapsulation in the code, they aim at make code re-usable and structured. Many of these design patterns could also be used in R, maybe by using the proto library, or standard R object orientation?
My questions are:
What base code (S3, S4) / packages (proto, R.oo) can I use to reproduce design patterns as for example mentioned in the book by Gamma et al?
Are there examples of design patterns implemented in R, both in base R, or in packages?
Some examples of design patterns:
The system.time() function seems to behave much like a decorator pattern. However, almost exclusively decorators are mentioned in the context of object oriented programming. But still, it has the feel of a decorator, it extends (or decorates) an existing piece of code (in OOP always an object) with additional functionality without any need to change the piece of code. Here system.time() is shown in action:
system.time(bla <- Sys.sleep(1000))
#jverzani posted an example of singleton pattern on github.
An example of a Strategy Design Pattern is the apply family of functions. The functionality of looping over the given object is generic, the function that is applied (the strategy) is chosen when the user supplies the function.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Because it is not really* possible to create abstract classes in objective-c I was wondering if anyone could tell me why the creators of objective-c didn't add this feature to the language.
*of course there are a few workarounds to create a -kind of- abstract classes but thats not what i mean.
If you mean why you can't declare a class abstract rather than just implement it as an abstract class, I suppose it's because it doesn't interact so well with Objective-C's extremely dynamic, types-optional, Smalltalky message-passing style (Smalltalk doesn't have built-in support for declaring them either). For example:
You might not know what class you're sending alloc or init to, so it would be a pretty weak guarantee
Subclasses might still need to pass alloc and init up the class hierarchy, so we'd need to allow that, making it an even weaker guarantee
Categories modify classes at runtime, making it the abstract contract weaker still
In the end, you'd wind up with a keyword that just did roughly the same thing we do now to implement abstract classes (i.e. maybe override init to bail if the receiver isn't a subclass).
Type modifiers that just specify a contract become more useful the more you rely on the static type system — but Objective-C was designed not to rely on the type system all that much, so putting the contract in the type system is less useful than in some other languages.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I think it is not necessary for me to explain what is the good thing about OOP. But I would like to know discuss is the static method violate the OOP design? or a more OOP way to do is making a singleton to do such static method?
I would like to know what harm is done by static methods and what purpose is served by adhering to object oriented purity.
This question and its answer makes as much sense as any other argument about object-oriented purity and where a particular language falls on the continuum.
C# and Java both support the notion of methods and attributes associated with classes rather than a specific instance.
The benefit or harm of singletons in design have been explored in detail elsewhere.
Static methods wouldn't exist if they were considered to be bad practice in the OOP paradigm. Static methods are absolutely necessary at times, if you know how to use them. If you have a method that does not make use of, or change, any member of a class object, then it is static by nature.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Object orientation is probably the most dominant programming paradigm today. Some people say, there are certain disadvantages, flaws or faults to this paradigm. Some even consider it a complete failure. What are the concrete reasons/arguments for that?
What I found the biggest flaw of OOP is that the most prominent frameworks/methods encourage writing not object-oriented code. If we are developing service and DAO layer with no state at all (just business methods passing arguments from layer to layer) and have a domain model with no logic at all (just a bunch of fields and maybe getters/setters/properties), it is no longer OOP. Most of the enterprise projects, even considered to be well written, aren't actually object oriented. They have a collection of functions grouped together in logical namespaces (called classes) and a collection of data structures, having private fields to annoy programmers (called domain). The domain does not have any operations.
IMHO OOP model was sacrificed in enterprise applications because it does not handle concurrency properly (or maybe because people prefer to have a stable set of objects rather than creating new instance per request ?!?). This is probably the reason why functional languages (and immutable objects to some degree) are getting much more attention.
On the other hand, are immutable objects actually in the spirit of OOP? I am not sure.