oop - Scala, trait inheritance and chaining, handling specialized method call -
i'm novice in using advanced oo techniques of scala. think have idea of how trait chaining works. still not sure when inherit trait in trait, , when use 'self' type. nor have ever used dependency injection if relevant.
edit: i've removed analogies , used actual domain problem since appeared wasn't clear in question. hope makes question simpler now.
every searchable entity can searched name. if entity physically located, can searched location well. if entity exhibit summary can searched summary. search, need map of weights assign each of these components.
i have trait searchable, , traits implement it: physicallysituated, exhibit. code looks this:
trait searchable{ def getweight() = { val name: string println( "getweight in searchable" ) map( name -> 20 ) } } trait physicallysituated extends searchable{ val city: string val country: string override def getweight() = { println( "getweight in physicallysituated" ) super.getweight ++ map( city -> 5, country -> 5 ) } } trait exhibit extends searchable{ val summary: string override def getweight() = { println( "regular getweight in exhibit" ) super.getweight ++ map( summary -> 3 ) } } class school extends searchable physicallysituated exhibit class book extends searchable exhibit
now want create specialized version of getweight
of exhibit
based on whether 'full search'. version take parameter getprecise: enumeration
, return precise weight includes description.
object exhibit{ object search extends enumeration{ val includedescription = value val excludedescription = value } } trait exhibit extends searchable{ val summary: string override def getweight() = { println( "regular getweight in exhibit" ) super.getweight ++ map( summary -> 3 ) } def getweight( getprecise: exhibit.search.value ) = { println( "specialized getweight in isgestating" ) super.getweight ++ if( getprecise == exhibit.search.includedescription ) map( summary -> 4 /*4 != 3*/, description -> 2 ) else map( summary -> 3 ) } } object traitchaining extends app{ //weight depends on order. println( ( new searchableentity exhibit physicallysituated). getweight( exhibit.search.includedescription ) ) println( ( new searchableentity physicallysituated exhibit). getweight( exhibit.search.includedescription ) ) }
the purpose want serve there times when want include description in search when i'm doing full search , know collection of searchable's has exhibits too
mycollection.filter( _.isinstanceof[ exhibit ] ).map( _.asinstanceof[ exhibit ].getweight( getprecise = exhibit.search.includedescription ) ). ++ mycollection.filter( !_.isinstanceof[ exhibit ] ).map( _.getweight ).sum //i know ++ change order
am thinking of things right way, or pattern no-no oo point of view?
my reservation because of 2 things:
1) order of traits inheritance matters in case, major problem. makes me wonder if problem amenable oop patterns. 2) if there trait derived from, , had criterion 'precise search'? (i use @millhouse answer inspiration that, pass set of flags instead of single flag, , each trait worries own
if not right way, right way handle this? hope you've understood intent of question. please respond if think you're expert in oo , understand scala traits well. hope answer takes time add value providing new information (no offence)
as stated @millhouse in comment of question, modelling properties change on time trait
s. trait resolution done @ compile time, if istantiate livingbeing
extending isgestating
trait, being in state forever.
the use of trait
s you're trying use known implementation of decorator design pattern in scala. reported in this link, in scala
the delegation established statically, @ compile time, that’s enough long can arbitrarily combine decorators in place of object creation.
oop concept @ higher level of abstraction programming languages. then, each programming language realizes oop concept in different way, still adhere them.
in case, need model evolutionary mechanism, allows change state of livingbeing
. example, can use decorator pattern not directly applying livingbeing
, applying internal object models state change properties on time.
Comments
Post a Comment