Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I am currently going through the design patterns of OPP. Just to give you some background. This is not my first time encountering the patterns. I've been programming for a while (decade or so) and I am pretty familiar with many programming principles, especially SOLID. I've been mostly doing web applications development, so maybe I am missing something that could've been learnt in different programming areas.
As the title suggests, I am struggling with grasping deeper the abstract factory pattern. I do understand the definition and also the "when to use the pattern" parts, but I am still missing the point. Especially when adding the Open closed principle from SOLID to the equation.
What do I mean?
The image above is taken from the Design Patterns book from GOF.
To make this post really a question of sort, there are two things that I myself can not find answer to:
When you study Open closed principle it stays that classes should stay closed for modifications. The implementation it results into is something approximating Strategy pattern. When you look at the method structure of AbstractFactory, it lists all the products it creates as separate methods. This means when we want to add new product to the family, we need to modify the AbstractFactory and create new method. Is this not a violation of Open closed principle? Maybe there is not better way to do this, is it?
Secondly, could anyone provide me with some real world example besides the ones used in the books (WidgetFactory - GOF, PizzaStore - HeadFirst)? Do you have any common implementations where you can say "Yes, this is something I usually implement with Abstract factory"? When is Abstract factory truly useful? Or am I understanding the pattern well, but it's just not that common in web development?
I hope I somehow managed to express my uncertainties regarding the pattern. In any case feel free to ask follow up questions, I'll be happy to provide more details.
Thank you in advance!
Dan
The implementation [OCP] results into is something approximating Strategy pattern.
Possibly. There are multiple ways to fulfill the OCP. Bertrand Meyer originally touted inheritance when he defined the principle.
...when we want to add new product to the family, we need to modify the AbstractFactory and create new method. Is this not a violation...
Possibly. It depends on how you implement the pattern, but the GoF book does acknowledge this problem on page 90.
Supporting new kinds of products is difficult. Extending abstract factories to
produce new kinds of Products isn't easy. That's because the AbstractFactory
interface fixes the set of products that can be created. Supporting new kinds of
products requires extending the factory interface, which involves changing
the AbstractFactory class and all of its subclasses. We discuss one solution to
this problem in the Implementation section.
The solution mentioned in the GoF book is to parameterize the AbstractFactory method, which results in its own set of problems.
...it's just not that common in web development?
No, it's not. Dependency Injection was not a common pattern when the GoF book was written, but today it has all but replaced the need for Abstract Factories. I would almost be willing to go so far as to call Abstract Factory an anti-pattern today; but I remain open-minded that there could be a problem better suited to AF than DI. I just haven't seen one yet.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Whenever a setup-wizard is used, then the user answers many different things until the real installation can be started. Comparing this with a class in my current project: I have a class that requires multiple configuration steps. It is not for an installer, but I thought that installer wizard is a good way to explain the required larger configuration functionality.
I am trying to find a good design solution.
My current solution approaches:
Flat: I could define one large class with all steps included as methods/functions/properties. Either a few control methods could be added to throw exceptions when calling the wrong methods. It would do its work, but a programmer would be confused seeing so many different methods. (-> he would require more time to understand how it works)
Hierarchy: I could create about 3 different classes for each configuration step. Each has its own methods and functions. Finally one class would require an instance of all 3 configuration-classes in its constructor. This would not look too confusing, since only the correct methods are visible in each class. However, a programmer may be annoyed, that a small class requires such a complex preparation, creation of 3 other classes. Maybe nested classes, but I think this would also be a bad coding-style.
I wonder if someone has already experience with such a problem and can answer this by.. Either providing a fitting design pattern, or some experience/best practices class structures for such problem.
I have searched for similar questions, have checked some design patterns that may fit, and already provided 2 approach ideas to show in what direction an answer could go. If you think that the answer is not clear enough, please comment/ask about the missing part.
From what is explained in the question and comments, the "single class to rule them all" approach seems to be no good choice.
Perhaps some kind of strategy pattern is the way to go here.
Instead of a very complicated setup of your single class, you choose from different strategies depending on what your requirements are. If you already know that there
will be about three different things that can happen, make three different strategies.
Lets make an example:
You want to write log data. Perhaps to a file, a database or a webservice.
Then you have only a single dependency to a "LogWritting Strategy" which has
a clearly defined interface, lets say
interface ILogWriter
{
void Write(enum LogLevel, string logEntry);
}
Now, in your client code, you depend on that interface and just make calls on the interface. But at runtime, you "inject" a concrete strategy based on your "configuration".
I.e. you just select the suiting strategy and you do not have a complicated bootstrapping of a single class.
Then you use concrete strategies like
IDatabaseLogWriter
IFileLogWriter
IWebServiceLogWriter
A brief explanation of what strategy is about can be found here:
Strategy pattern
Update
from the most recent comment I think that both Repository and Mapping patterns can help.
You should consider looking at
Repository pattern, good explanation
Repository explanation by Martin Fowler (top notch architecture)
Metadata mapping
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I was reading this paper from Apple:
http://developer.apple.com/library/mac/documentation/cocoa/conceptual/OOP_ObjC/OOP_ObjC.pdf
where it talks about OOP which I never heard before. I graduated in computer science around 1991, before OOP becoming popular, so the use of OOP was merely defining some classes, and then calling the methods, that's it. Objects didn't interact with each other -- everything was done in a main function that calls the various objects' methods.
Until I read the paper above, which talks about Interface, dynamic typing, dynamic binding, that an object can send another object a message, even before the second object is invented -- only the "interface", or the message, needs to be well defined. The second object can have unknown data type as of right now, to be invented in the future, but all it needs to do is to understand the "message".
So this way, each object interacts with one another, and each object may have a list of "outlets" which are the relationship it has with the outside world, and the object will interact with the outlets by sending them messages, and those objects, when getting a message, can in turn send back a messages to the sender. (send a message to an object = call the object's method).
I think this sort of opened my eye for OOP, much more than even the Design Pattern book by the Gang of Four. The Apple paper didn't cite any source, but I wonder it might follow some methodology from a book? Does any OOP book give a good, solid foundation in OOP which is what the Apple paper is talking about?
Nice introduction to OOP is "Coffee maker" (and quite short).
I personally really enjoy reading "Object thinking".
Another interesting book is "Domain-Driven Design: Tackling Complexity in the Heart of Software".
Next in my to-read list is "Object Design: Roles, Responsibilities, and Collaborations".
Try Elegant Objects (I'm the author). It is rather practical and, at the same time, pays a lot of attention to the theory. You must have some programming experience beforehand though.
I am from .Net background and I am planning to read the following book to address this question.
Foundations of Object-Oriented Programming Using .NET 2.0 Patterns - Christian Gross
What I am finding interesting about this book is
Use of generics
Explaining patterns as a solution to a problem
Object orientation can easily get out of hand. For example, with increasing complexity, dependency management becomes burdensome if not done properly.
Thus, as a moderating set of literature, I'd recommend Uncle Bob's articles on the Principles of Object Oriented Design.
Smalltalk 80 The Language and its Implementation by Adele Goldberg and David Robson. Best OOP book ever. Also relevant is the Byte Magazine August 1981 issue.
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 5 years ago.
Improve this question
I know very well about the traditional arguments about why Interface Inheritance is prefered to multiple inheritance, there has been already a post here :
Should C# have multiple inheritance?
But according to Stroustrup the real reason why Microsoft and Sun decided to get rid off multiple inheritance is that they have vested interest to do so: instead of putting features in the languages, they put in frameworks so that people then become tied to their platform instead of people having the same capability at a language standard level.
What do you think ?
Why Sun and Microsoft consider developers too immature to just make the choice themselves ?
Above is my explicit interpretation of what he said. Of course he did say that in a more politically-correct way :)
Excerpt from "A Conversation with Bjarne Stroustrup"
http://www.artima.com/intv/modern.html
People quite correctly say that you
don't need multiple inheritance,
because anything you can do with
multiple inheritance you can also do
with single inheritance. You just use
the delegation trick I mentioned.
Furthermore, you don't need any
inheritance at all, because anything
you do with single inheritance you can
also do without inheritance by
forwarding through a class. Actually,
you don't need any classes either,
because you can do it all with
pointers and data structures. But why
would you want to do that? When is it
convenient to use the language
facilities? When would you prefer a
workaround? I've seen cases where
multiple inheritance is useful, and
I've even seen cases where quite
complicated multiple inheritance is
useful. Generally, I prefer to use the
facilities offered by the language to
doing workarounds.
From "Interview of Bjarne Stroustrup by "Developpeur Reference""
http://www2.research.att.com/~bs/nantes-interview-english.html
You can always re-write an example using multiple inheritance into on the uses single inheritance only (by using forwarding functions). However, the result is often an example that is longer, reflect the design less directly, and is harder to maintain. Note that you can also rewrite every example using single inheritance to an example using no inheritance using the same technique and with the same negative impact on code clarity. A language that does not support multiple inheritance is simply less expressive than one that supports multiple inheritance and thereby forces the programmer to occasionally complicate code.
...
People talk a lot about frameworks, but history is littered with frameworks that didn't live up to their expectations. I have seen successful frameworks, but they were generally limited in scope. I'm skeptical of "universal" frameworks, and even more so when such frameworks are products of a platform vendor competing with similar frameworks from other vendors. As a user, I prefer to maintain my independence from vendors as far as possible.
I'd like to seen libraries providing cleaner and more general access to frameworks - as opposed to languages intimately tied to a single framework.
My own thought:
People do follow fashion and IT is no exception. Nobody dares to question the fundamentals until some Gurus have themselves interest to do so.
For example in the case of Java nobody dared to question EJB until Rod Johnson came along with another framework which he said was inspired by .NET pragmatism.
And now .NET is becoming itself more and more frameworklish with EF.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
What is a good challenge to improve your skills in object oriented programming?
The idea behind this poll is to provide an idea of which exercises are useful for learning OOP.
The challenge should be as language agnostic as possible, requiring either little or no use of specific libraries, or only the most common of libraries. Try to include only one challenge per answer, so that a vote will correspond to the merits of that challenge alone. Would also be nice if a level of skill required was indicated, and also the rationale behind why it is a useful exercise.
Solutions to the challenges could then be posted as answers to a "How to..." question and linked to from here.
For example:
Challenge - implement a last-in-first-out stack
Skill level - beginner
Rationale - gives experience of how to reference objects
Building Skills in Object-Oriented Design is a free book that might be of use.
The description is as follows:
"The intent of this book is to help the beginning designer by giving them a sequence of interesting and moderately complex exercises in OO design. This book can also help managers develop a level of comfort with the process of OO software development. The applications we will build are a step above trivial, and will require some careful thought and design. Further, because the applications are largely recreational in nature, they are interesting and engaging. This book allows the reader to explore the processes and artifacts of OO design before project deadlines make good design seem impossible."
Write a challenging program from scratch. Try to get some people (around five, that should be doable) to use it. Respond to their change requests.
Adapt your program's design. Start small, then watch it grow. Manage this growth. This is hard. You will also have to fix bugs and maintain the thing over time, which for me was a very valuable lesson.
Challenge: Write a wrapper for your web site/service API of choice in your language of choice, that doesn't already exist (ex. a ZenDesk API wrapper written in C#). Release the wrapper as open source for others to use.
Skill Level: Beginner to Intermediate
Rationale: To learn how to extrapolate a 3rd party web service API into a meaningful set of objects/classes, making the reuse of that API easier in your chosen language.
After you have learned the basics, study the "Gang of four" design patterns book.
http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1221488916&sr=8-1
This is a classic, and a must read for any coder who wants to understand how to use OO to design elegant solutions to common coding problems.
Take a procedural-style written piece of code and try to transform it into OOP based solution. During the process, consult a book on refactoring and design patterns. A friend of mine was able to make a huge step forward in understanding object oriented concepts exactly this way. As with anything, this might not work for everyone.
I have found CRC cards to be quite effective in learning, teaching and building good OO design.
Certainly a good challenge, although less accessible than a "start from scratch" assignment, is to refactor some existing code that either doesn't use inheritance or doesn't use very much of it to make greater use of inheritance. The process of refactoring will expose a lot of the benefits and gotchas of oop, as it certainly has for me on my most recent project. It also pushed me to understand the concepts better than past projects have where I've created my own object oriented designs.
A given task has very little to do with being "OOP", it's more in how you grade it.
I would look at the Refactoring book, chapter 3, and make sure none of the bad code smells exist in the solution. Or, more importantly, go over ones that do apply.
Most importantly, watch for the existence of setters and getters (indicating that you are operating on values from a class and not asking the class to operate on it's own values)--or using "extends" without applying the Liskov Substitution Principle, stuff like that.
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 4 years ago.
Improve this question
An answer to a Stack Overflow question stated that a particular framework violated a plain and simple OOP rule: Single Responsibility Principle (SRP).
Is the Single Responsibility Principle really a rule of OOP?
My understanding of the definition of Object Orientated Programming is "a paradigm where objects and their behaviour are used to create software". This includes the following techniques: Encapsulation, Polymorphism & Inheritance.
Now don't get me wrong - I believe SRP to be the key to most good OO designs, but I feel there are cases where this principle can and should be broken (just like database normalization rules). I aggressively push the benefits of SRP, and the great majority of my code follows this principle.
But, is it a rule, and thus implies that it shouldn't be broken?
Very few rules, if any, in software development are without exception. Some people think there are no place for goto but they're wrong.
As far as OOP goes, there isn't a single definition of object-orientedness so depending on who you ask you'll get a different set of hard and soft principles, patterns, and practices.
The classic idea of OOP is that messages are sent to otherwise opaque objects and the objects interpret the message with knowledge of their own innards and then perform a function of some sort.
SRP is a software engineering principle that can apply to the role of a class, or a function, or a module. It contributes to the cohesion of something so that it behaves well put together without unrelated bits hanging off of it or having multiple roles that intertwine and complicate things.
Even with just one responsibilty, that can still range from a single function to a group of loosely related functions that are part of a common theme. As long as you're avoiding jury-rigging an element to take the responsibilty of something it wasn't primarily designed for or doing some other ad-hoc thing that dilute the simplicity of an object, then violate whatever principle you want.
But I find that it's easier to get SRP correct then to do something more elaborate that is just as robust.
None of these rules are laws. They are more guidelines and best practices. There are times when it doesn't make sense to follow "the rules" and you need to do what is best for your situation.
Don't be afraid to do what you think is right. You might actually come up with newer and better rules.
To quote Captain Barbossa:
"..And secondly, you must be a pirate for the pirate's code to apply and you're not.
And thirdly, the code is more what you'd call "guidelines" than actual rules...."
To quote Jack Sparrow & Gibbs.
"I thought you were supposed to keep to the code."
Mr. Gibbs: "We figured they were more actual guidelines. "
So clearly Pirates understand this pretty well.
The "rules" could be understood via the patterns movement as "Forces"
So there is a force trying to make the class have a single responsibility. (cohesion)
But there is also a force trying to keep the coupling to other classes down.
As with all design ( not just code) the answer is that it depends.
Ahh, I guess this pertains to an answer I gave. :)
As with most rules and laws, there are underlying motives by which these rules are relevant -- if the underlying motive is not present or applicable to your case, then you are free to bend/break the rules according to your own needs.
That being said, SRP is not a rule of OOP per se, but are considered best practices to create OOP applications that are both easily extensible and unit-testable.
Both are characteristics that I consider as of utmost importance in enterprise application development, where maintenance of existing applications occupies more time than new development does.
As many of the other posters have said, all rules are made to be broken.
That being said, I do think that SRP is one of the more important rules for writing good code. It's not specific to Object Oriented programming, but the "encapsulation" part of OOP is very hard to do right if the class does not have a single responsibility.
After all, how do you correctly and simply encapsulate a class with multiple responsibilities? Usually the answer is multiple interfaces and in many languages that can help quite a bit, but it's still confusing to the users of your class that it may apply in completely different ways in different situations.
SRP is just another expression of ISP :-) .
And the "P" means "principle" , not "rule" :D