I've a class diagram like this:
TopClass
◆ ◆
| |
SubClass1 SubClass2
◆ ◆
| |
| ChildClass2
|
ChildClass1
TopClass has SubClass1 and SubClass2.
Subclass1 has ChildClass1 and ChildClass2.
I use dependency injection on each of these classes. So when ChildClass1 needs interface X I need to pass X thru TopClass and Subclass1. When ChildClass2 needs Y I also need to pass it thru whole hierarchy. Eventually I end up with TopClass full of dependencies to interfaces it actually doesn't use. I find it smelly.
I've found an article about facade pattern which seemd promising but eventually I cannot find a way to use it in my situation.
Any other idea? And I wouldn't like to use singleton or any similar solution as I need to be able to unit tests these classes easily.
EDIT
Another option which I just found and which I'm going to test for a while is boost.DI:
http://boost-experimental.github.io/di/cpp-london-2017
http://boost-experimental.github.io/di/
Related
how can I get a list of all the methods an object can understand?
for example:
set := 8 getAllMethods
will give me all methods 8 can understand in set
In code you can use allSelectors:
set := 8 class allSelectors
gives you a set of all the names of messages (a. k. a. selectors) that 8 can understand.
If you need the CompiledMethods instead of only the message names, you can use lookupSelector:
| class |
class := 8 class. "will be SmallInteger"
set := class allSelectors collect: [:each | class lookupSelector: each]
If you don't want to do this in code but rather find out in the IDE which messages an object can understand, then I propose to use the protocols browser (a. k. a. Lexicon tool). You can open it via "browse protocol" from the context menu of a class:
I used it to find allSelectors and lookupSelector:, which are inherited from Behavior and not defined in Class itself.
This is interesting because of the following. At first glance one might be tempted to consider an expression like this one
anObject class withAllSuperclasses gather: [:class | class methodDictionary]
which gathers all the methods implemented in the class and its superclasses. However, if a method is defined in a class and in one of its superclasses, we should ignore the latter because anObject will use the one in the class.
To remedy this side-effect of the above script we need to gather only the methods that are defined in the class which is closer to anObject class. One way to do this is to enumerate the classes from top to bottom, adding all their methods to a Dictionary. Since the dictionary will only retain the last element added to a given key (in this case a selector), only the ones that belong in the protocol of anObject will survive:
methods := Dictionary new.
anObject class withAllSuperclasses reverseDo: [:class |
methods addAll: class methodDictionary associations].
Note the use of reverseDo: for enumerating the classes downwards.
Another approach would be to enumerate the classes from bottom to top, checking whether the selector has already been visited:
methods := Dictionary new.
anObject class withAllSuperclasses do: [:class |
class methodDictionary do: [:cm |
methods at: cm selector ifAbsentPut: [cm]]]
(were cm stands for CompiledMethod)
The second version is a bit longer, more complex (it has two loops, one nested inside the other) and needs conditional logic (#at:ifAbsentPut:). In other words, it shouldn't be the one chosen.
Note
When looking for ways to create a collection (in this case the collection of all methods understood by an object), first make sure you really need such a collection. For instance, you will need the collection if you want to display it on the screen. However, if you are only going to use the collection for membership checking, there might be other ways to proceed. In your case, you could simply ask the object:
anObject respondsTo: <selector>
and in case the answer is true, recover the method using
anObject class lookupSelector: <selector>.
This is both simpler and more efficient because it doesn't create collections, etc.
I'm trying to call a function from another class (Binario) but it says it's not implemented.
This is the code for the method in Binario class:
genlista
^ (1 to: 30) collect: [ :i | 2 atRandom - 1 ]
And this is the code for the other class method:
ListadelistasBin
| bin |
bin := Binario new.
^ (1 to: 30) collect: [ :i | bin genlista ]
Please, help me :(
Most likely #Uko is right and you defined the method in the class side of Binario rather than in the instance side. One way to check this would be to modify your second method like this:
ListadelistasBin
| bin |
bin := Binario. "<- new removed"
^ (1 to: 30) collect: [:i | bin genlista]
If now you get the answer, then what happened is that your genlista method is in the wrong place (class side instead of instance side).
In Smalltalk every method belongs in a class. However, there are two "sides" of a class. The instance side is where you put methods for the instances of the class. The class side is where you put methods for the class itself.
How can you tell in what side of a class you have saved a method? Just look for the switch that every browser has to select one or the other side. In Pharo, for example, there is a toggle button that you use to select each of the sides.
While instance methods define the behavior of the instance of your class (and subclasses), class methods are meant to be sent to the class. This is just a consequence of classes being objects. For example, Binario new is a message sent to the class Binario, and we believe that your intention was to define the genlista method for instances of Binario. If this is the case, then copy the source code of the method and paste it on the instance side of the class. Then remove the class method and try again. Ah! and don't forget to put the new message back next to Binario in your ListadelistasBin!
First of all mixins are not the best solution, since my interfaces are large and I want to avoid writing empty implementations.
What I am looking for is which approach (technique) is the best for multiple inheritance. My problems is diamond inheritance (yes I read about diamond problem).
// -----------------------
// | Edit |
// -----------------------
// / \
// / \
// / \
// ----------------------- -----------------------
// | DataSetEdit | | OEdit |
// ----------------------- -----------------------
// \ /
// \ /
// \ /
// -----------------------
// | ODataSetEdit |
// -----------------------
The logic is simple.
Edit is basicaly some <input type="textbox"> with some additional method for validation, masks, input checking ...
OEdit extends edit with some additional methods for styling. Can get properties from server application (WebSocket), send events to server
DataSetEdit adds methods and properties for handling edit properties (text, color, caption, placeholder ...) - automatically handle changes when current record has changed. (DataSet is class and its data is Object[].)
ODataSetEdit extends OEdit functionality but need also DataSetEdit methods for handling changes on DataSet.
In one project I use DataSetEdit and in another I always use ODataSetEdit. So in project where ODataSetEdit is used, I only need to copy DataSetEdit functionality.
I do not want to duplicate code in DataSetEdit and ODataSetEdit.
I was thinking if I can solve this with:
some static methods/properties approach
decorators (maybe on constructor to extend class functionality)
some static method on DataSetEdit which would be called from ODataSetEdit to extend OEdit functionality with DataSetEdit
proxy methods and properties from ODataSetEdit to DataSetEdit
some sort of composition (how would design looks in this concrete example)
ODataSetEdit should extend OEdit but be able to use functionality added in DataSetEdit.
I think that the class structure is logic, how can I avoid need for multiple inheritance in my design? I am sure this is a common problem not related to TypeScript.
how can I avoid need for multiple inheritance in my design
Move the logic out of OEdit into functions / variables (feel free to use a namespace : https://basarat.gitbooks.io/typescript/content/docs/project/namespaces.html to collect these into something meaningful) and then share them between OEdit and ODataSetEdit.
More
Fundamentally you need to move the logic out into a place accessible by at least one direct child and the grand child. No two ways around it 🌹.
Let's say I have inheritance like this
Person
|
+-----+------+
| |
Student Teacher
Then I would call Person the Base.
How would I call Student?
Inherited class sounds stupid. Is there a single word for it?
Basically using Base for super class, so: PersonBase
And for it's implementations it's common to add Impl like: StudentImpl and TeacherImpl
Superclass -> Vehicle |
Subclasses -> Car & Bike
If the class Car requires a startCar() method (which outputs
a string of value 'BRUMM' when invoked) and even the class
Bike requires a similar method startBike() (which outputs
a string of value 'TRUMM' when invoked) Would it be better
to go about it this way, or instead have a startVehicle()
method in the superclass Vehicle which is coded differently for
the different outputs for the respective subclasses: Car and Bike?
Edit: Bike refers to Motor Bike
First, instead of using startCar() and startBike() [and startVehicle()] respectively, the function could [and should] just be called 'start()' (e.g. Car.start(), Bike.start(), Vehicle.start()), as each function shares the same intention, and is designed to give the same type of output.
Now, if most/all of your subclasses are going to implement a start function then I'd recommend creating the start() function in the superclass, and then overriding it in the subclasses.
Additionally, if Car.start() and Bike.start() share a lot (but not all) of the same functionality (e.g. they both start an engine of some sort), then put the similar code into the Vehicle.start(). Then, when you write Car.start() and Bike.start() to override Vehicle.start(), the respective functions should call Vehicle.start() method, before running their class-specific code.
P.S. Definitely do not code the superclass's start() function to put out a different value based on a class's actual type; basically a superclass shouldn't have to know about the subclass... otherwise, what's the point? :)