I am having the following problem:
I obtain an object from an external component and what I'd like to do is override several of the object's functions in order to change parts of its behavior.
I tried doing this via a decorator by inheriting from the original object's class and storing the original object as a member variable, but then I would have to override all the functions in that object.
I also don't have access to most of the object's internal data, so I cannot just clone it into my derived object's base class.
So bottom line is: is there anyway to override a couple of an already instantiated object's functions while retaining the data and not having to override the entire object functionality?
Thanks,
PM
The short answer is, No.
The longer answer is to write a wrapper around it and yes that means implementing all the methods. YOu can do this via composition.
.Net isn't a dynamic language although it has some dynamic feature but I don't think you component will be dynamic.
Can you not inherit the object its self and then just add your methods to it?
If this isn't possible I'd store the component in a variable and then replicate all of the components methods. Not the nicest of the solutions but it would work, I just hope the component doesn't have to many methods.
Finally have you tried if your license agreement allows it using something like reflector on it, might show up a possible solution.
Related
I'm currently learning Kotlin through the Kotlin Android Developer program from Udacity. There's two sample apps using DiffUtil.ItemCallback, but declare it in different ways. Both sample apps use a ListAdapter, however one declares the DiffUtil like this: companion object DiffCallback : DiffUtil.ItemCallback<MarsProperty>()
while the other like this: class SleepNightDiffCallback: DiffUtil.ItemCallback<SleepNight>()
Both DiffUtils are passed as parameters to the ListAdapter, with the only difference being that in the case of the class implementation, it has to be initialised:
class PhotoGridAdapter : ListAdapter<MarsProperty, PhotoGridAdapter.ViewHolder>(DiffCallback)
class SleepNightAdapter : ListAdapter<SleepNight, SleepNightAdapter.ViewHolder>(SleepNightDiffCallback())
The only difference between those sample apps is that one downloads and shows images from the internet (the one with the PhotoGridAdapter), while the other shows data from a database, so
my question is: Is one implementation preferred compared to the other? Are there any performance differences between them?
This is probably a matter of opinion. Mine is that the callback should be an object, or anonymous object, but not a companion object.
All it's doing is comparing properties of two objects. It doesn't have to hold any state. So it makes sense for it to be a singleton object rather than a class that you have to instantiate. Whether you define it as a named singleton object or define in place as an anonymous object assigned to a property doesn't make much different in communicating intent.
But it doesn't make sense to me to make it a companion. It's already nested and has a name. All companion does is suggest that you should need to call its functions directly and that the name PhotoGridAdapter should also be thought of as a callback. For instance, it enables you to pass the name PhotoGridAdapter to some other adapter as its DiffUtil callback, which is nonsensical. The only reason it might possibly make sense is if you also want to use it as a utility for comparing items, so you could call functions like PhotoGridAdapter.areContentsTheSame directly. However, I don't think this is likely. Usually, the contents of the callback's functions are either very trivial like passing through equals() or they are very specific to the nature of updating the displayed list.
I'm trying to do some polymorphic deseralization of JSON using Jackson, however the list of subclasses is unknown at compile time, so I can't use a #JsonSubtype annotation on the base class.
Instead I want to use a TypeIdResolver class to perform the conversion to and from a property value.
The list of possible subclasses I might encounter will be dynamic, but they are all registered at run time with a registry. So I would appear to need my TypeIdResolver object to have a reference to that registry class. It has to operate in what is essentially a dependency injection environment (i.e I can't have a singleton class that the TypeIdResolver consults), so I think I need to inject the registry class into the TypeIdResolver. The kind of code I think I want write is:
ObjectMapper mapper = new ObjectMapper();
mapper.something(new MyTypeIdResolver(subclassRegistry));
mapper.readValue(...)
However, I can't find a way of doing the bit in the middle. The only methods I can find use java annotations to specify what the TypeIdResolver is going to be.
This question Is there a way to specify #JsonTypeIdResolver on mapper config instead of annotation? is the same, though the motivation is different, and the answer is to use an annotation mixin, which won't work here.
SimpleModule has method registerSubtypes(), with which you can register subtypes. If only passing Classes, simple class name is used as type id, but you can also pass NamedType to define type id to use for sub-class.
So, if you do know full set, just build SimpleModule, register that to mapper.
Otherwise if this does not work you may need to resort to just sharing data via static singleton instance (if applicable), or even ThreadLocal.
Note that in the end what I did was abandon Jackson and write my own much simpler framework based on javax.json that just did the kinds of serialisation I wanted in a much more straightforward fashion. I was only dealing with simple DTO (data transfer object) classes, so it was just much simpler to write my own simple framework.
Which is better of the two
Creating properties and passing it within methods in class or passing objects as parameters to a method?
I have a datamodel object instance returned by a handler class, which i want to pass it to two different methods, so what is the best approach, assing it to a property in the class and then use it into these two methods, or pass the instance as a parameter to the method?
If an object is only needed temporarily by a class to extract data from for example, then pass it as an method argument.
You should take a step back from the code details and have a more abstract look: If the object has no direct purpose, or does not meaningfully belong with the class, then passing it as a method argument is fine. If the object could be seen as a part of the class (i.e. something the class needs all the time, or relies on a lot), then it might be an option to make it part of the class using a property.
Something else to consider is that setting a property, and then call a method that uses that property, separates the data from the operation. I mean, this obscures what the method does, and on what data it works. Of course this could be overcome by correct naming of those methods. Again look at things at a bit more abstract level to find the most meaningful way (i.e. what is closest to the purpose of the class and what the methods are actually doing) of structuring things.
In other cases these object may belong to underlying/other classes, which means that your current class is only passing them on. In those cases it's clear that you should literally pass them on with methods.
I'm playing around with composition of a couple of objects.
I have two classes (Note and task). The Task class is derived from the Note class as a task is an extented note.
Each note has a property Property Child as list (of note) as a note or task could be added to an existing note or task (Therefore this 'child' note could be a task or a note)
ie.
dim x as new note()
x.Child.item(0).Child.item(0).Child.item(0).description.ToString()
the final child note object is actually a task, how can i make this aggregation work? i don't care if its a note or a task but I would like to release the functionality of the base or the extended class.
My immediate thoughts were that each object needs to have a list of tasks and a list of notes but it feels like there could be a more elegant solution.
Does anybody have any thoughts on this?
You're collection of Note objects should already give you what you want.
If you need to differentiate between Note and Task you can ask if the instance is a 'typeof' Task and then cast appropriately to get at the derived properties and methods.
If the methods and properties you need are part of the base class, you don't need to cast, you can rely on polymorphism to call the type-appropriate method/property.
If I understand you correctly, you should be implementing the behaviour of your class with what us C# folks call virtual methods / properties... Essentially they use late bound calls so that the appropriate functionality is called from the correct class - be that the parent or the derived class.
I think the VB.Net equivilent is "Overrideable" and "Overrides".
I had a bunch of objects which were responsible for their own construction (get properties from network message, then build). By construction I mean setting frame sizes, colours, that sort of thing, not literal object construction.
The code got really bloated and messy when I started adding conditions to control the building algorithm, so I decided to separate the algorithm to into a "Builder" class, which essentially gets the properties of the object, works out what needs to be done and then applies the changes to the object.
The advantage to having the builder algorithm separate is that I can wrap/decorate it, or override it completely. The object itself doesn't need to worry about how it is built, it just creates a builder and 'decorates' the builder with extra the functionality that it needs to get the job done.
I am quite happy with this approach except for one thing... Because my Builder does not inherit from the object itself (object is large and I want run-time customisation), I have to expose a lot of internal properties of the object.
It's like employing a builder to rebuild your house. He isn't a house himself but he needs access to the internal details, he can't do anything by looking through the windows. I don't want to open my house up to everyone, just the builder.
I know objects are supposed to look after themselves, and in an ideal world my object (house) would build itself, but I am refactoring the build portion of this object only, and I need a way to apply building algorithms dynamically, and I hate opening up my objects with getters and setters just for the sake of the Builder.
I should mention I'm working in Obj-C++ so lack friend classes or internal classes. If the explanation was too abstract I'd be happy to clarify with something a little more concrete. Mostly just looking for ideas or advice about what to do in this kind of situation.
Cheers folks,
Sam
EDIT: is it a good approach to declare a
interface House(StuffTheBuilderNeedsAccessTo)
category inside Builder.h ? That way I suppose I could declare the properties the builder needs and put synthesizers inside House.mm. Nobody would have access to the properties unless they included the Builder header....
That's all I can think of!
I would suggest using Factory pattern to build the object.
You can search for "Factory" on SO and you'll a get a no. of questions related to it.
Also see the Builder pattern.
You might want to consider using a delegate. Add a delegate method (and a protocol for the supported methods) to your class. The objects of the Builder class can be used as delegates.
The delegate can implement methods like calculateFrameSize (which returns a frame size) etc. The returned value of the delegate can be stored as an ivar. This way the implementation details of your class remain hidden. You are just outsourcing part the logic.
There is in fact a design pattern called, suitable enough, Builder which does tries to solve the problem with creating different configurations for a certain class. Check that out. Maybe it can give you some ideas?
But the underlying problem is still there; the builder needs to have access to the properties of the object it is building.
I don't know Obj-C++, so I don't know if this is possible, but this sounds like a problem for Categories. Expose only the necessary methods to your house in the declaration of the house itself, create a category that contains all the private methods you want to keep hidden.
What about the other way around, using multiple inheritance, so your class is also a Builder? That would mean that the bulk of the algorithms could be in the base class, and be extended to fit the neads of you specific House. It is not very beautiful, but it should let you abstract most of the functionality.