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.
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.
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.
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.
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.
There are various books written for Design Patterns ranging from "Design Patterns: Elements of Reusable Object-Oriented Software" to "Pattern-Oriented Software Architecture Volume 1-4".
But, I did not found any good book which explains Objects Oriented Design, how to design classes, interfaces, etc for large scale and complex systems and make system design as simple as possible through those techniques.
Please share your thoughts about it.
A couple of the most obvious:
Object Oriented Analysis and Design With Applications (Grady Booch)
Object Oriented Software Construction (Bertrand Meyer)
IMHO good OOD is about keeping modules as small, compact and consistent as possible (e.g. the "SOLID" principles). Therefore, good large-scale OOD is "just" a bunch of good small-scale OOD together.
The only thing that really changes in larger scale systems is the importance of getting the smaller scale bits right. Get your abstractions in good order before you get down to actual code.
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.
I find myself rarely using object oriented principles when I design applications. I am looking for a good reference for Object Oriented design. I'm using C# as my programming language and would like to have a reference which helps to make use of the OO contructs provided by C#. But basically I need a good book to derive some inspiration.
Here goes: two milestones
Design Patterns: Elements of
Reusable Object-Oriented
Software
Head First Design
Patterns
I think a book on Design Patterns may be what you want. The classic one would be Deisgn Patterns: Elements of Reusable Object Orientated Software.
Check out Evan's DDD