Reputation
1,079
Top tag
Next privilege 2,000 Rep.
Edit questions and answers
Badges
7 18
Impact
~23k people reached

  • 0 posts edited
  • 0 helpful flags
  • 150 votes cast
Dec
24
comment Pattern for caching DAOs: strategy or decorator?
@Hey I think memoization is an alternative that uses a more functional approach. In this case functions are memoized by wrapping them into another function that is smart enough to use a cache when necessary. The proxy sounds more like OO approach. I guess depending on the implementing language one or the other could be more easily achieved.
Dec
24
comment Pattern for caching DAOs: strategy or decorator?
Well, I am certainly not a world class expert on the subject, but I think the conceptual difference here is that the decorator is supposed to forward requests to its decorated component object. It may optionally perform additional operations, before and/or after forwarding the request, but the forward always happens. With a proxy the story is different, and in the case of a cache you may decide never to forward the request to the proxied object if the cache is still fresh and alive.
Dec
24
comment Pattern for caching DAOs: strategy or decorator?
Actually I have seen this most commonly implemented as a proxy pattern.
Dec
24
comment Why lambda/closures expressions came so late to C++?
@Doval Precisely my point. Closures and lambda expressions were already pretty, pretty popular before LINQ. The fact that Java and C# are mainstream programming languages have simply make them more popular than they were to more programmers. Above all to those who have never programmed in other languages and were probably unfamiliar with the topics this might sound like revolutionary, but for many others there is not a big surprise here.
Dec
24
comment Why lambda/closures expressions came so late to C++?
@SK-logic I have to disagree on the influence of LINQ. Closures are the oldest trick in the book. They existed before the first computer was ever created and they first appear in LISP in the late 50s, ML (70s), Haskell (80s) then other languages adopted them Python, Ruby, JavaScript, then a rebirth of functional programming in 2000 with Scala, Clojure and F# among others. Actually C# and Java are the oldest languages to adopt this. Now you are not going to say that LINQ popularized high order programming. This is just the result of the natural evolution of languages.
Aug
11
awarded  Popular Question
Jun
1
comment Condition to use polymorphism
Already answered: Is polymorphism possible without inheritance
Apr
26
awarded  Yearling
Apr
24
awarded  Popular Question
Apr
7
comment When too much encapsulation was reached
You may consider reading this paper by Alan Snyder Encapsulation and Inheritance in Object-oriented Programming Languages. There are copies in PDF around the web. Also you may consider this another answer about encapsulation.
Apr
1
comment How to avoid programmers duplicating code
See the problem from another angle, instead of thinking that the problem is the code duplication, we may consider if the problem originates in the lack of policies for code reuse. Recently I read the book Software Engineering with Reusable Components and it indeed has a set of very interesting ideas on how to foster code reusability at the organization level. I will answer in the related question.
Apr
1
answered How do I prevent unknowningly duplicating code?
Mar
31
revised Question/Answer for multiple Users - How should I design it?
added 1 characters in body
Mar
31
revised What should a repository really do?
deleted 1 characters in body
Mar
31
revised What should a repository really do?
added 1638 characters in body
Mar
31
answered What should a repository really do?
Mar
31
revised Question/Answer for multiple Users - How should I design it?
edited body
Mar
31
answered Question/Answer for multiple Users - How should I design it?
Mar
31
answered How does Observer create loosely-coupled design?
Mar
30
comment Make a java program use more processors
Well, this sounds like the kind of work JDK 8 Parallel Streams were created to solve.