I am writing verification IP for some interface and facing with one interesting item, which I think is somehow basic for OOP.
So in my driver I have functions e.g. configMaster, which is DUT specific. And VIP user may want to override that function. Now I want to provide mechanism for user to do that.
I think the best way of overriding the VIP driver class functions would be following
User extends the driver class
In the extended class user redefines the driver methods that he wants. If there are several methods that user doesn’t want to override that’s fine.
Using factory override method user overrides the driver class with the
extended user_driver class
The thing I don’t like here that user each time running the simulation should specify the factory override command.
Could you please share your opinion is this right way to do? Are there other ways?
Thanks
Hayk
Step 3 is not always mandatory . After overriding the class the user can directly use the derived class in his TB. This will mostly be the case if the TB is being built afresh or the user is integrating this IP as a new component into an existing TB.
In case the VIP was already present in a TB and you are now providing new set of functions to the user to override or the user itself want to use the override mechanism preferring to instantiate the base class provided by the VIP and use the override mechanism later , user can use the set_type_override_by_type function .
The function can be embedded into a base test and all the derived test will implicitly use the use vip class derived by the user without the need to specify it explicitly in the command line for each test case.
There are 4 flavor to the type override function .
http://www.testbench.in/UT_06_UVM_FACTORY.html
The function can also be used in a base env too , the user has to ensure that the type override function is called before the class is create for the override mechanism to take effect.
Related
Does anybody knows why BlockData class doesn't directly implement IContent?
I know that during BlockData is being retrieve from database, proxy created by Castle implements IContent.
If StackOverflow isn't suitable place for this kind of a question, please move it.
Johan Björnfot at EPiServer explains some of the details in this post.
Excerpt:
"In previous versions of CMS was pages (PageData) the only content type that the content repository (traditionally DataFactory) handled. In CMS7 this has changed so now content repository (IContentRepository) handles IContent instances. This means that the requirement for a .NET type to be possible to save/load from content repository is that it implements the interface EPiServer.Core.IContent.
There are some implementations of IContent built into CMS like PageData and ContentFolder (used to group shared block instances) and it is also possible to register custom IContent implementations.If you look at BlockData though you will notice that it doesn’t implement IContent, how is then shared block instances handled?
The answer is that during runtime when a shared block instance is created (e.g. through a call to IContentRepository.GetDefault where T is a type inheriting from BlockData) the CMS will create a new .NET type inheriting T using a technic called mixin where the new generated subclass will implement some extra interfaces (including IContent)."
BlockData does implement IContent as it is intended to work both when added to another content item such as a PageData instance (a.k.a. Local Block), and as a standalone instance (a.k.a.Shared Block). In latter case the interface is added by using a mix-in though Castle Windsor so that it can be referenced.
The decision for this construct was based on wanting to be able to use the same rendering templates regardless if a block is local or shared. Therefor the choice stood between having a large number of empty properties on local blocks or the current solution using mixins. Both options were tested and mixins was selected as the preferred solution even though it's not a perfect one.
BlockData "does implement IContent", just do:
var myContent = (IContent)myBlock;
But, if you're by any chance handling a Block which itself is a property (not a ContentReference), that cast will throw an exception.
This will be true for 100% of all cases (... using Math.Round).
The Login method of the Authentication service takes four arguments, the last being a string customData.
public T Login(string userName, string password, bool isPersistent, string customData);
I would like to know how this customData parameter can be used. I don't see how it given the membership provider (since the membershipProvider ValidateUser takes only username and password), and I don't see how it is used by the AuthenticationBase Domain Service.
What I don't understand is this statement, from the documentation
customData: Optional implementation-specific data. It is unused by
this base class.
If it is unused by the base class, how is a derived class suppose to use it, since the Login method is not virtual?
I need to pass additional authentication data as part of the login process and I was rather hoping that there would be a few extensible points on the server side that would make using the customData possible.
The AuthenticationBase implements the IAuthentication interface and that is where the Login method is defined. If you create your own DomainService that implements IAuthentication directly instead of inheriting AuthenticationBase then you can use the customData.
I've been researching ways to store global settings for my Android application and so far the best way seems to extend the Application class and store the shared data inside it, as described here. I've discovered that instead of using (CustomApplicationClass)getApplicationContext().getSomething() i can do the same thing by referencing directly to the static method inside the class like this: CustomApplicationClass.getSomething() and both ways work just fine.
Here's a piece from CustomApplicationClass:
public class CustomApplicationClass extends Application {
private static boolean something;
#Override
public void onCreate() {
[...]
}
public static boolean isSomething() {
return something;
}
public static void setSomething(boolean something) {
this.something = something;
}
}
Now, if i want to retrieve value of "something" variable somewhere in my code, say, from my application Activity, is there a difference between:
boolean var1 = ((CustomApplicationClass)getApplicationContext()).isSomething();
and
boolean var1 = CustomApplicationClass.isSomething();
? When running the application, both work fine. Is the second way safe to use, or is it inadvisable?
I've been researching ways to store global settings for my Android application and so far the best way seems to extend the Application class and store the shared data inside it, as described here.
Except that you're not doing that.
I've discovered that instead of using (CustomApplicationClass)getApplicationContext().getSomething() i can do the same thing by referencing directly to the static method inside the class like this: CustomApplicationClass.getSomething() and both ways work just fine.
Of course. You could just as easily had CustomApplicationClass extend Object, then executed CustomApplicationClass.getSomething(). You are gaining nothing by your current approach versus just using an ordinary singleton pattern in Java, and you are losing flexibility, as an application can only have one custom subclass of Application.
Is the second way safe to use, or is it inadvisable?
The first way is pointless, since your data member and methods are static.
Either:
Make your stuff in CustomApplicationClass not be static, and then use getApplicationContext().
Refactor CustomApplicationClass to not extend Application, and then use the static data member and/or accessor methods, or switch more formally to the Java singleton pattern.
Personally, I would go with option #2.
If you check the api of android.app.Application (http://developer.android.com/reference/android/app/Application.html) then you will find on Class Overview as following:
Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's tag, which will cause that class to be instantiated for you when the process for your application/package is created.
There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.
In this stackoverflow question I learned that Prism/Unity is not as decoupled as I thought, e.g. if I have this class which gets menuManager injected into its constructor, then I have to make sure that this class actually exists somewhere (I thought that you could just pull the .dll that contains the class and the container would deal with it, e.g. injecting a null in its place):
public class EmployeesPresenter
{
public EmployeesPresenter(IMenuManager menuManager)
{
}
}
But I can deal with that: the application cannot run without a MenuModule (or else as was suggested I could have a NullMenuModule which does nothing but keeps the application from breaking).
However, the application I am building will have a MenuManager class in the MenuModule and every module will have to register everything it wants to have in the menu with the MenuManager. However, I want to be able to swap out MenuModules e.g. have a InfragisticsMenuModule and have a TelerikMenuModule, etc.
However, when I am in e.g. the CustomersModule, in order to use TelerikMenuModule, I need to reference it. And when I want to use InfragisticsMenuModule, I need to reference that.
So how will I be able to "hot swap" TelerikMenuModule with InfragisticsMenuModule without recompiling all my modules with new references, e.g. I want to replace this:
Application.exe
Customers.dll
TelerikMenuModule.dll
with this:
Application.exe
Customers.dll
InfragisticsMenuModule.dll
and simply be able to restart the application and it runs with the new InfragisticsMenuModule.dll and does not complain that TelerikMenuModule.dll no longer exists.
This is where interfaces come in. You need something like:
public interface IMenuSystem
{
// whatever operations need to be offered by a menu system
}
Application.exe and Customers.dll may only refer to that interface. They aren't allow to know about a specific implementation.
Then you would use configuration steps (calling Register... methods or using a config file) to specify which type will provide the implementation of MenuSystem.
For obvious reason MEF comes to mind here and is designed for stuffs like this. I haven't had a chance to use Unity, so I'm not sure if it has something built in like this (i.e. scanning a directory for an IMenuModule implementation), but MEF can do this.
Suggestion also is to put this IMenuModule in a common assembly (separate from your other assembly). I usually called this thing Something.Core.dll.
So you might have: Application.exe, Customer.dll, Application.Core.dll, and your specific MenuModule implementation.
Your specific MenuModule implementation will reference the Application.Core assembly to gain access to its IMenuModule interface and implement it there.
When using FxCop 1.36 for a WPF application with a single window that has yet to be modified, I get the InterfaceMethodsShouldBeCallableByChildTypes error with the following details:
Target : #System.Windows.Markup.IComponentConnector.Connect(System.Int32,System.Object) (IntrospectionTargetMember)
Resolution : "Make 'MainWindow' sealed (a breaking change if
this class has previously shipped), implement the method
non-explicitly, or implement a new method that exposes
the functionality of 'IComponentConnector.Connect(int,
object)' and is visible to derived classes."
Help : http://msdn2.microsoft.com/library/ms182153(VS.90).aspx (String)
Category : Microsoft.Design (String)
CheckId : CA1033 (String)
RuleFile : Design Rules (String)
Info : "Explicit method implementations are defined with private
accessibility. Classes that derive from classes with
explicit method implementations and choose to re-declare
them on the class will not be able to call into the
base class implementation unless the base class has
provided an alternate method with appropriate accessibility.
When overriding a base class method that has been hidden
by explicit interface implementation, in order to call
into the base class implementation, a derived class
must cast the base pointer to the relevant interface.
When calling through this reference, however, the
derived class implementation will actually be invoked,
resulting in recursion and an eventual stack overflow."
Created : 08/12/2008 22:26:37 (DateTime)
LastSeen : 08/12/2008 22:41:05 (DateTime)
Status : Active (MessageStatus)
Fix Category : NonBreaking (FixCategories)
}
Should this simply be ignored?
Ignore it, this is standard code that is in every WPF application and you don't see people complaining about net being able to call IComponentConnector.Connect from derived classes - so it's probably safe.
In general I think you should handle FxCop output as suggestions that have to be considered carefully, I've got a lot of bad advice from FxCop in the past.
Depends on what you expect an inheriter to do.
If you are not expecting this class to be inherited then it should be sealed and the problem goes away.
If you are expecting it to be inherited then you are taking the ability of the inheriting class to override the interface methods and still call them (i.e. base.methodname()). If that is your intent then you can ignore the warning.
However, that is not expected behaviour for inheritable classes so you should expose the interface publicly (i.e. An implicit interface instead of an explicit interface).