I often use a framework that allow you to inherit from a certain class, and override a method there, and it will be invoked.
from the framework point of view, how is it done ? what pattern is this ?
Sounds like you are using a programming language / platform which provides metadata for the code. The metadata is used by the framework to find any classes which implement the certain class.
It's not a specific design pattern (not one that I know of in any way) but a technique which can be applied in most modern languages. For instance, ASP.NET uses this for it's global.asax file (and I use it in a .NET framework of mine).
It's typically used for application entry points to control the lifetime of the object.
Not sure in what context you are using the word framework, but what you describe sounds like polymorphism.
Related
I know this question might seem to be answered before, but I feel that the answer varies from case to case, so after reading several posts, I'm not sure in my case which is the best for my architecture.
I have a Component Library that has a Data Model and basic functionality that should be available to any application implementing this component.
I have a boundary for this component which has an interface IReader to load and process files from the disk and IDataMapper to provide Database access and CRUD operations.
a few other interfaces for specific functionality like IObjectComparison to compare objects, IXMLSerialization fro XML serialization.
I'm not sure where to store the definition of these interfaces.
The options are:
1)- Within the core Library, then when I write the implementations I will have to include the implementation libraries within this core component with I'd like to maintain decopled from the implementations.
2)- In a separate library project (Assembly). All interfaces there and included to the core component and included by the implementation libraries.
3) - In the implementation Libraries, then the core component will have to include the implementation libraries.
The only case where it seems reasonable decoupled is if I put all interfaces in a separate assembly library where Core component includes and any implementations I might need.
What do you guys think are Pros/Cons of the best option?
All I want to achieve is a decoupled architecture.
So when I do
Constructor:
CoreComponent(IReader Reader, IDataMapper Mapper)
new CoreComponent(WindowsReader, SQLServerMapper)
and don't have to include WindowsReader or SQLServerMapper into the Core Component
Cheers.
I would go for option 1 - Core Library as it is accordance with how we do in DDD. In DDD we used to put IRepository interfaces in Domain Layer instead of DAL or any other such layer.
DIP says the higher level component would own the interface, as Wikipedia says...
where interfaces defining the behavior/services required by the high-level component are owned by, and exist within the high-level component's package.
This is most common practice but not a strict rule.
Option 2 is fine but you need to refer two DLLs in other projects but with option 1 only one reference is needed. Option 3 is not appropriate.
Hope it would help. Thanks.
I know there are numerous aspect-oriented frameworks for VB.NET. It's a little heavy to pull an entire framework into play in order to add an aspect to a couple methods. Does VB.NET offer a simple means (via some sort of metaprogramming/reflection) in which to layer an aspect over an existing method in a class/object?
Basically, the goal is intercept a method's incoming message to invoke it and add side effects or to manipulate the request, just as one would normally do in standard AOP.
Are there any plans to integrate aspects directly into the language?
Is polymorphism not an option in this case? I think you'll find that, outside of an AOP framework of some kind, there is no way in VB to change the functionality of an existing class. You can inherit and override base members, or you can use extension methods to add additional functionality to an existing class, but there's no way to alter existing functionality in an existing class.
It is possible to create a new library that mimics another existing library and trick existing code into thinking your new library is the original one, but unless absolutely necessary, this is a bad idea. Chances you just need to rethink your design in a standard OOP way rather than thinking in AOP terms.
How about the decorator (or proxy) pattern? Since it's only a few methods, then you only need one or two decorator classes. If you discover later that it's not just one or two methods, then you can consider bringing in an AOP tool.
Here's an example in C# that should translate pretty easily to VB.NET
A little background: We're building a library/framework for working with scientific models. We have an interface Model which defines the operations that a model must implement, which is pretty minimal. That is: the Model interface defines the contract of a model from the point of view of a model implementor.
The framework adds a bunch of other functionality around the model, but right now client code has to access that functionality by using a bunch of other classes, such as ModelInfo, ModelHost, ModelInstance, etc.
In our application that uses this framework, we don't want to actually have to deal with all this mechanism of running models, etc. So we've decided to use the façade pattern to wrap up the framework functionality in an easy-to-use object. (We've already applied this pattern to other parts of the framework, with good success.)
Here is the question: given that we already have an interface Model, what would be a good name for the façade class? The Model interface is the contract between the framework and the model implementation, and the new class will define the contract between the framework and the client application.
Or, more generally: when we have an abstraction provided by a library or framework, how can we name the "two sides" of the abstraction so as to clearly identify the "provider" and "consumer" interfaces to the abstraction?
(If it matters, for this project we're using Java 6.)
I know this seems trite, but... have you considered using "ModelFacade" as the class name for the facade class? I think with documentation that indicates that the interface was already named Model, it seems relatively straightforward, and makes it very clear which design pattern you're using.
How about *Provider and *Consumer? I think you said it yourself in your question. Perhaps *Producer and *Consumer is a better match?
In discussions within our team, another option has been proposed: we can rename the existing Model interface to something else, and just call the new façade Model. In fact, they can both be called Model right now, because they will live in separate packages. (Although I'm not a fan of identically-named classes in different namespaces.)
Sounds like ModelInfo, ModelHost, and ModelInstance should all be members of Model.
See https://softwareengineering.stackexchange.com/questions/316840/is-it-bad-practice-to-name-a-class-with-a-facade-suffix for why you generally shouldn't name classes with the specific implementation used. Basically, some day you may want to use a different implementation of Model, which happens to not be a facade.
PureMVC uses a singleton named ApplicationFacade and registers all the models with methods like registerProxy which are defined in IFacade
What are possibles designs for implementation of the DCI (data, contexts, interactions) architecture in different OOP languages? I thought of Policy based design (Andrei Alexandrescu) for C++, DI and AOP for Java. However, I also thought about using State design pattern for representing roles and some sort of Template method for the interactions... What are the other possibilities?
Doing pure DCI is tough in most language you usually run into one of two problems. Statically typed languages such as Java usually ends up with some kind of wrapper solution which creates a self schizofrenia problem. Dynamic languages that let you attach new instance methods at will at run time often suffers from a scoping issue. The RoleMethods are still available when the object is no longer playing the role.
Best fits I know of for different languages
Marvin: Design for DCI and as such has full support
Ruby using Maroon. If you are using the maroon gem (or similar) then there's full support for DCI in Ruby.
Java: Qi4J
C# Extension methods (Scoping issue and overload issue) possibly together with dynamic. I've had an implementation based on Clay but that creates an identity problem
Native Ruby: Method injection Scoping issue with methods being available when the object no longer plays the role
C++: Templates. Scoping issue method life span is the same as the object life span
if you take a look at fullOO you will find examples in a few languages. Including in my own project Marvin which is a language specifically designed to support DCI. At present most of Marvin is identical to C# so you could say it's an extension to C# more than a language of it's own right.
In Java, without byte-code generation, I would use Decorator pattern for contexts, however I will instead of classes decorate interfaces, which will be more flexible. Data than will be represented through classes implementing the interfaces. The interactions will be done using manual dependency injection into Template methods.
When do you recommend integrating a custom view into Interface Builder with a plug-in? When skimming through Apple's Interface Builder Plug-In Programming Guide I found:
Are your custom objects going to be used by only one application?
Do your custom objects rely on state information found only in your application?
Would it be problematic to encapsulate your custom views in a standalone library or framework?
If you answered yes to any of the preceding questions, your objects may not be good candidates for a plug-in.
That answers some of my questions, but I would still like your thoughts on when it's a good idea. What are the benefits and how big of a time investment is it?
It's perfectly reasonable to push the view and controller classes that your application uses out into a separate framework — embedded in your application wrapper — for which you also produce an Interface Builder plug-in.
Among other reasons, classes that are commonly used in your application can then be configured at their point of use in Interface Builder, rather than in scattered -awakeFromNib implementations. It's also the only way you can have your objects expose bindings that can be set up in Interface Builder.
It's a bit of coding, but for view and controller classes that are used in more than one place, and which require additional set-up before they're actually used, you'll probably save a bunch of time overall. And your experience developing with your own controller and view classes will be like developing with Cocoa's.
I think the Apple guidelines sum it up nicely.
If you're writing a control that will be used in multiple applications and is completely generic, then creating a custom object is a good idea. You'll be able to visualize the look and set properties directly from Interface Builder.
If your control is limited to one application, or is tightly coupled with your data, then moving it into a custom object really won't buy you much.
It's not difficult to create a custom view, there are a lot of easy to follow guides out there.