Does bridge pattern (intent) allow to use additional implementer types in descendant abstractions? Or this approach violates smth? Or maybe it's a misuse of the pattern? Example:
Thanks in advance!
You've just used the bridge pattern twice. There's no problem with that.
Even if you don't need to support more abstraction-style subclass of CAbstractionB, you should probably do this, because the Abstraction hierarchy is about the services provided and you don't want to confuse this by mixing in an implementation hierarchy at the leaves.
Related
What is the point in using this pattern?
Considering this article it's just senseless: https://refactoring.guru/design-patterns/factory-method
Why not to use simple inheritance?
Here's a little comparison:
https://codesandbox.io/s/factory-method-pattern-vs-good-old-inheritance-opovv?file=/src/inheritance.ts
There is no one versus the other; Factory Method uses polymorphism, via inheritance, to defer object creation to subclasses.
Don't confuse patterns as being greater than their constituents. Patterns are simply names for common use cases of software design, because anything important deserves a name.
Are there languages that idiomatically use both notions at the same time? When will that be necessary if ever? What are the pros and cons of each approach?
Background to the question:
I am a novice (with some python knowledge) trying to build a better picture of how multimethods and interfaces are meant to be used (in general).
I assume that they are not meant to be mixed: Either one declares available logic in terms of interfaces (and implements it as methods of the class) or one does it in terms of multimethods. Is this correct?
Does it make sense to speak of a spectrum of OOP notions where:
one starts with naive subclassing (data and logic(methods) and logic implementation(methods) are tightly coupled)
then passes through interfaces (logic is in the interface, data and logic implementation is in the class)
and ends at multimethods (logic is in the signature of the multimethod, logic implementation is scattered, data is in the class(which is only a datastructure with nice handles))?
This answer, to begin, largely derives from my primary experience developing in common-lisp and clojure.
Yes, multimethods do carry some penalty in cost, but offer almost unlimited flexibility in the ability to craft a dispatch mechanism that precisely models whatever you might look to accomplish by their specialization.
Protocols and Interfaces, on one hand, are also involved with sone of these same matters of specializations and dispatch, but they work and are used in a very different manner. These are facilities that follow a convention wherein single dispatch provides only a straightforward mapping of one specialized implementation for a given class. The power of protocols and interfaces is in their typical use to define some group of abstract capabilities that, when taken together, fully specify the API for thus concept. For example, a "pointer" interface might contain the 3 or 4 concepts that represent the notion of what a pointer is. So the general interface of a pointer might look like REFERENCE, DEREFERENCE, ALLOCATE, and DISPOSE. Thus the power of an interface comes from its composition of a group of related definitions that, together, express a compete abstraction -- when implementing an interface in a specific situation, it is normally an all-or-nothing endeavor. Either all four of those functions are present, or whatever this thing us does not represent our definition of pointer.
Hope this helped a little.
Dan Lentz
The necessity for protocols are to abstract the methods of classes which are not hierarchically related.
The similar things also can be done with the help a class (interface) which encompasses all those methods and subclass them ? (This is not really possible due to the Multiple inheritance problem since a class has to be derived already from NSObject.ignore the NSProxy case)
What special things that protocols can do than a class?
Are protocols trying to solve only the multiple inheritance problem?
Protocols main advantage is, that they describe what a object should be able to do, without enforcing subclassing. In languages that dont have multiple inheritance such a mechanism is needed, if you want others programmers be able to use your classes. (see delegation)
For an instance Java has something similar, called interfaces.
This means a huge advantage, as it is very easy to build dynamic systems, as I can allow other developers to enhance my classes via a clearly defined protocol.
A practical example:
I am just designing a REST API and I am providing a Objective-C client library.
As my api requires information about the user, I add a protocol
#protocol VSAPIClientUser <NSObject>
-(NSString *)lastName;
-(NSString *)firstName;
-(NSString *)uuid;
#end
Anywhere I need this user information, I will have an basic id-object, that must conform to this protocol
-(void)addUserWithAttributes:(id<VSAPIClientUser>)user;
You can read this line as: "I don't care, what kind of object you provide here, as long as it knows about lastName, firstName and uuid". So I have no idea, how the rest of that object looks like — and I don't care.
As the library author I can use this safely:
NSDictionary *userAttributes = #{#"last_name" : [user lastName],
#"first_name": [user firstName],
#"uuid": [user uuid]};
BTW: I wouldn't call the absence of multi-inheritance a problem. It is just another design.
“[…] If I revisited that decision today, I might even go so far as to remove single inheritance as well. Inheritance just isn’t all that important. Encapsulation is OOP’s lasting contribution.” — Brad Cox was asked, why Objective-C doesn’t have multiple inheritance. (Masterminds of Programming: Conversations with the Creators of Major Programming Languages, p. 259)
As an alternative view....
Object-oriented programming's most basic value comes from being able to model real-world relationships directly as opposed to translating them into abstract and vaguely-equivalent computer-world constructs. Wherever a language requires you to think about the implementation of a solution in different terms than those you can use to describe your problem, it is flawed as an OOP tool. (Note that I didn't say 'useless'. :) )
Real-world objects have various roles that depend on context. Those roles can have state. Therefore, I agree that lack of multiple-inheritance is an impediment to ease of modelling. Objective-C protocols, Java interfaces, and the claim that you should prefer composition to inheritance are all denials of a fundamental part of the OOP advantage.
One of many uses of C++ abstract classes is, among their other uses, to define interfaces (to specify reusable contracts). There are however also other programming languages, such as Objective C that have a separate concept for interfaces in this sense; in Objective C, it is called protocols.
A wide use of such a construct does require a way of attaching more than one contract to an object; and if such interfaces are allowed to inherit from each another, this has to be multiple inheritance to be useful.
However, this is not the same thing as multiple inheritance between classes.
Protocols are not trying to solve the multiple inheritance problem. They are trying to separate contract specification from object (data+code) specification. They can actually do much less than a class (if you ignore the multiple inheritance aspect) and that's why they exist as a separate concept.
Implementing a protocol is generally a much less restrictive (safer) proposition to consider than inheriting from a class.
Or the "extends" is a use case inheriting another?
--update
Just a clarification, I've read books and made a lot of diagrams. But I just can't see any difference between extends on UML and on inherance. As Bill said, UML extends indicates optional behavior, but in inherance either you get new behavior you can or not use. So, what's the difference?
I think in UML the difference is in that "extends" is based on extension points, which means there has to be a named point in the use case where the extension will be applied. The semantics are not very precise about this. Inheritance for use cases means changing some behaviour, not exzactly specifying where.
Another important point is about the inheritance and the Liskov substitution principle. You should be able to use one use case, which inherits from another, in any place you can use the another one. This does not hold for the way "extends" is understood. When one use case is extended by another, it means that one might be modified by another, but still it contains the main scenario path, which might be forked and joined by the extending use case. This is, I think, about the difference between structural and behavioural inheritance. Inheritance is about achieving the same goal and satisfying the same interests - same responsibility and behaviour constraints, where extension is about modification of the structure of the path of scenario, which might be triggered by additional interests - like error checking.
Inheritance actually is not a very good mechanism to be used for use cases, combined with actor inheritance, which makes more sense, it can lead to unwanted paradoxes. Following the advice of Alistair Cockburn (Writing effective Use Cases), inheritance should be used only for expressing variations in technical details or data formats for a particular use case.
This is very similar to inheritance. See a detailed description of this concept here.
Enjoy!
In the tool I use in my company we have modeling restrictions.
Inheritance:
From Actor to Actor, from UseCase to Usecase, from System to System. You can't have other inheritances in your diagram because I got a forbidden sign.
Extend can only be done between two Usecases and not between other elements.
I don't really see the difference between inheritance and extends between two usecases.
I will keep on reading the next posts because after reading all answers I still don't understand:-)
Extends is used to add additional, optional, behavior to the use case that is being extended, but does not change any of the behavior in the base use case.
An inheriting use case would replace one or more of the behaviors of the inherited use case. In other words changing the behavior of the base use case, rather than simply adding new functionality. Note that use case inheritance is not quite the same as class inheritance.
See this article.
What is the difference between an 'Abstraction' and a 'Facade'?
Is there a difference at all? Or are the terms interchangeable?
The facade pattern is an simplified interface to a larger, possibly more complex code base. The code base may be a single class, or more. The facade just gives you a simple interface to it.
Abstraction, is used to represent a concept, but not to be bound to any specific instance. (Ie: An abstract class). This doesn't imply simplifying (like the facade pattern does), but rather making a 'common' interface or representation.
Facade is a specific design pattern, meant to hide the internal stuff inside a package / module from its clients behind a well-defined interface. It usually hides several interfaces/classes behind a single common one, hence its name.
'Abstraction' is a general term, meaning to hide the concrete details of something from the outside world.
So these two are not interchangeable terms.
Facade is a GoF design pattern, very specific. In essense, it's about hiding over-complex functionality from the main body of your application.
Abstraction is a more vague term related to hiding functionality of a service from its client.
Abstract to me means taking the common parts of a collection of things and creating a base thing from them, which the collection can then draw on, sort of like a parent class.
A façade is a face (literally speaking), so they analogy of a base class doesn't quite hold. A façade is more of an interface, so it wouldn't have to be related to the things that use it. I think of it more like a mask. My class will have a "disposable" mask, for example.
So the difference, in my mind, is that an abstract pattern allows a hierarchy to be built, where as a façade pattern allows classes look similar.