This question already has answers here:
Why use inheritance at all? [closed]
(13 answers)
Closed 7 years ago.
What is main purpose of inheritance in OOP? i'm new in programming but I think maybe could be code reuse, are there more purposes or a more important purpose?
The main purpose of inheritance in Object Orientated Programming (OOP) is to give the user ability to change the behavior of the libraries, without actually changing already working and debugged code.
Changing other people's code always has a risk of introducing bugs because you may not fully understanding how the code works. In OOP, the user inherits the object and implements the behavior changes or new features with his own code, separate from the original code.
This way if there are bugs, the user needs to debug and fix only his own code, which is of course an easier task.
Related
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.
This question already has answers here:
VB.NET What is the purpose of a class or module?
(7 answers)
What's the point of OOP?
(45 answers)
Closed 8 years ago.
I understand how to create a class. I understand how to work with it in normal situations. However, I don't see the point of the reason. Can someone give clarification?
Well the point is to make coding more manageable. easier to add and ASSOCIATE functions, properties attributes etc than individually coding them as separate entities.
For instance you write functions to change system sound, one to increase it, other to decrease it and third to mute it. In non-OO languages they would literally be like Increasesoundfunc, Decreasesoundfunc and mutesoundfunc. while in OO they'd be like Soundclass.inreasesound, Soundclass.decreasesound ,Soundclass.mutesound . Horrible example, but you get the point.
Return to the Basics... A Class supposed to be a representation of an object from the real live, most of the time this is true, maybe its only how the computer its able to understand us.
Something its true about the classes: everything, every system, dll, framework, control, etc, etc, was made from a lot of classes.
hope it help you.... :)
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 8 years ago.
Improve this question
Lua beginner here, i am looking into lua.
my question is: since an object in Lua is just a table,
new fields can be added at runtime. if I have a typo in the code, and instead of changing a field, I create a new field, won't that bring mayhem? ;)
I would only be able to figure out the bug in runtime, if I even get to that point in the program.
(of course the table concept has other benefits like meta programming without reflection, but my question is about "safety" or predictability.)
Is that the right conclusion?
Yes, that is correct.
When working with a dynamically typed language, you'll need an extensive suite of unit tests, to make sure you cover all possible scenarios and prevent the kind of mayhem you described.
If you want to protect yourself from this, I'd recommend looking at a static typed language, such as java, c# or scala, and let the compiler do the type-checking for you.
This is why Twitter moved from Ruby to Scala - as the project grows, it gets progressively harder to keep track of bugs that can only be verified at runtime using a dynamically typed language - but could be verified at compile-time by a static language compiler.
Dynamic typed languages are based on duck typing:
If it walks like a duck, and quacks like a duck, it is a duck
I prefer this version:
If it walks like a duck, and quacks like a duck, it’s probably gonna throw exceptions at runtime.
Lua gives you the mechanisms to have at least as much safety as other dynamic programming languages with baked-in object models do. See here for instance.
Errors will still happen at runtime only though, so you need a test suite with decent coverage.
There are projects to add static typing to Lua. Fabien Fleutot, who created metalua, presented his at the latest Lua Workshop. See:
his slides
a high-level overview of his work
a more formal paper about it
This question already has answers here:
How does a delegate work in objective-C?
(5 answers)
Closed 7 years ago.
I have several documents and the videos on Stanford that explain it, but I still fail to get my head around what Delegation actually is.
I'm trying to picture them in a real use so I can relate to it.
Are the similar to event hooks? I've used event hooks in some PHP frameworks.
Sometimes I need things explaining in lamans terms before I can go "ah ha, I get it".
Thanks.
In software engineering, the delegation pattern is a design pattern in object-oriented programming where an object, instead of performing one of its stated tasks, delegates that task to an associated helper object.
Read this wikipedia article in detail.
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
Stackoverflow users,
How do you keep yourself from creating large classes with large bodied methods. When deadlines are tight, you end up trying to hack things together and it ends up being a mess that needs refactoring.
One way is to start with test driven development and that lends itself to good class design as well as SRP (Single Responsibility Principle).
I also see developers double clicking on controls and typing out line after line in the event method that gets fired.
Any suggestions?
I guess it depends on your internal processes as much as anything.
In my company, we practise peer review, and all code that gets comitted must be 'buddied in' by another developer, who you have to explain your code to.
Time constraints are one thing, but if I review code that has heinously long classes, then I won't agree to the check-in.
It's hard to get used to at first, but at the end of the day, it's better for everyone.
Also, having a senior developer who is a champion for good class design, and is willing and able to give examples, helps tremendously.
Finally, we often do a coding 'show and tell' session where we get to show off our work to our peers, it behooves us not to do this with ugly code!
Use a tool like Resharper and the Extract Method command.
Long classes is one bad code smell of many possible.
Remedying overly large classes by creating lots of small ones may create its own problems. New engineers on your project may find it difficult to follow the flow of the code to work out what happens where. One artifact of this problem can be very tall call stacks, execution nesting through many small classes.
Another suggestion is to do only what is asked. Don't play the "What if" game and try to overdesign a solution. This has the "Keep it simple, stupid" idea behind it.
We're a java and maven shop, and one of the...I guess you could say forensic methods we use are the excellent FindBugs, PMD and javancss plugins. All will give warnings about excessive length in a method, and the cyclomatic complexity calculations can be very eye opening.
The single most important step for me to avoid large classes that often violate SRP was to use a simple dependency injection framework. This freed me from thinking too much about how to wire things together. I only use constructor injection to keep the design free from cycles. Tools like Resharper help to initialize fields from constructor arguments. This combination leads to a near zero overhead for creating and wiring up new classes, and implicitly encourages me to structure behavior in much more detail.
This all works best if data is kept separate from behavior, and your language supports constructs like events that can be used to decouple communication that flows in the downward direction of the dependency graph.
use some static code analysis tools in your automated builds and write/configure/use some rules so that for example someone has to write a justification when he/she breaks it..