[VB.NET]Soort van Namespace in Class

[FireWood]

Ik heb een Class gemaakt waarin een vector gebaseerd plaatje met bijbehorende informatie wordt gecreëerd.

Nu bestaat die extra informatie voornamelijk uit "transform" opties. o.a. "scale", "rotate", "mirror"
Omdat de lijst nu een beetje lang is met voornamelijk deze transform opties wil ik deze graag groeperen zoals het met een namespace kan. Echter aangezien ik al in een Class werk kan ik geen namespace aanmaken om alle properties en in onder te brengen.

Ik heb al een aparte class gemaakt met daarin alle transform opties en deze kun je dan via een propertie "Transform" aanroepen. Dit werkt wel, maar is niet zoals het moet, aangezien transform niet een apart object is.

Ik heb m'n boekwerken al doorgebladerd, maar ik kan niet iets vinden waarmee je dit netjes kan oplossen.

[ThunderNet]

[google="vb.net enumerations"]

dat zoek je vermoed ik.

[ Voor 11% gewijzigd door ThunderNet op 29-02-2008 21:37 ]

[whoami]

Ik heb een sterk vermoeden dat je datamodel ruk is.
Zoals ik het nu lees, heb je één class, die 'alles' doet ?

(Verder vermoed ik ook dat je een method Transform bedoeld ipv een property ? )

[FireWood]

Blijkbaar niet goed uitgelegd:

Deze Class is alleen maar bedoelt als een data type.
Nu ziet deze class(een stukje) er zo uit

code:

Public Readonly Property Name
Public Readonly Property Discription
Public Readonly Property SVGImage

Public Property Mirror
Public Property Scale
Public Property Rotate

Ik vul eenmalig "Name, Discription en SVGImage" in d.m.v. new.
Daarna gaat dit door verschillende processen in en wordt de rest ingevuld(of niet).
als laatst wordt het plaatje gerenderd en op het beeldscherm geprojecteerd.

Nu is de lijst een beetje erg lang geworden. Voornamelijk door de "transform" properties.
Het enige wat ik eigenlijk wil is dat je die transform opties allemaal even in een aparte namespace zet o.i.d. zodat het wat opgeruimder wordt.

Ik kan een aparte class aanmaken voor alle transform opties en die apart weer toevoegen aan dit project, dit wil wel, maar dan gaat mijn datamodel juist omzeep.

BTW: Ik ben juist het model aan het opzetten, waarna ik hier tegen aanloop.

[ Voor 3% gewijzigd door FireWood op 29-02-2008 21:53 ]

[whoami]

Hmmm.... ik kan er niet veel over zeggen over dat model, maar ik heb er m'n twijfels over.

heb je in VB.NET niet zoiets als #region ?

[markvt]

Op deze manier krijg je een - voor de region en kan je je code inklappen (werkt alleen in visual studio).

code:

#Region "codemain"
    Sub Main()
        'dasasd
    End Sub


    'asdadsasd
    'asdasasd
    ''asdasdads


    'asdasdasd
#End Region

[FireWood]

whoami schreef op vrijdag 29 februari 2008 @ 21:59:
Hmmm.... ik kan er niet veel over zeggen over dat model, maar ik heb er m'n twijfels over.

heb je in VB.NET niet zoiets als #region ?

Ja, alleen klapt dit alleen de code in en kun je niet zoals in een namespace ook een extra stap nemen in je code.
Als jij het niet weet zal het wel niet bestaan.
Laat ik de lijst gewoon lang, op zich geen probleem alleen is wat minder overzichtelijk.

[whoami]

Ik vraag me toch af wat je precies met die properties wilt bereiken ?
Wat ga je bv doen of toekennen aan een property Rotate ?

[FireWood]

whoami schreef op vrijdag 29 februari 2008 @ 22:11:
Ik vraag me toch af wat je precies met die properties wilt bereiken ?
Wat ga je bv doen of toekennen aan een property Rotate ?

Rotate krijgt bv een hoekwaarde
De property controleert als de hoek niet meer is als 360 of negatief en rekent het zo nodig terug.
Daarna verdwijnt deze in een private integer in de class.
De property geeft het weer uit als er om gevraagd wordt.

De class doet niks anders, dan controleren van gegevens en het bij elkaar houden ervan.

[whoami]

En wat als ik die rotate property een waarde geef, en mirror een waarde, wat gebeurd er dan ? En wanneer wordt de rotatie en de spiegeling dan uitgevoerd ?

Is het niet beter om bv een RotateAction, een MirrorAction, etc... te maken (allemaal aparte classes dus), die op een image kunnen uitgevoerd worden ?
Als ik het goed begrijp, dan heb je nu gewoon één monolitische class die voor honderden dingen verantwoordelijk is / honderden functionaliteiten heeft, en op den duur gewoon ononderhoudbaar wordt ?

[RobIII]

Als je class te groot wordt is dat vaak (er zijn uitzonderingen uiteraard) al een teken van een slecht model; heb je te maken met 1 van de uitzonderingen dan kun je ook gebruik maken van partial classes.

Overigens maak je daarmee geen "extra stap"

[ Voor 23% gewijzigd door RobIII op 01-03-2008 13:32 ]

[Michali]

Je kunt wel een extra stap maken, maar dan zit je met een extra class waarin al deze properties zitten. Je vector afbeelding class krijgt dan een property van het type van die nieuwe class.

ipv. vectorImage.Rotate wordt het dan bijvoorbeeld vectorImage.TransformOptions.Rotate.

Maar het is wel vreemd om properties te hebben die de naam van een handeling hebben. Rotate klinkt namelijk als iets dat je uit kunt voeren en niet iets dat een bepaalde waarde heeft. Ik zou daarom eens sterk overwegen of hetgeen whoami als laatste zei niet is waar je naartoe wilt. Misschien voldoet het om deze properties gewoon een andere naam te geven, als dit niet logisch is, dan zou ik toch voor een andere oplossing gaan.

Moet het niet bijvoorbeeld RotateAmount zijn oid.?

[roy-t]

Visual Basic .NET:

public Class Model
{
    public Model(RotationObject rot, TransformationObjeft trans) //etc
}

En dan maak je gewoon meerdere objecten aan in 1 keer voor een nieuw model.
Desnoods kun je nog de volgende contructie gebruiken

Visual Basic .NET:

blaat = new Model(new RotationObject("lala", 1.0), new TransformationObject("zozo", 2.0));

Dat maakt je code denk ik wat simpelere. Pas op deze manier wel op voor privacy leaks ( http://www.cs.aau.dk/~nor...eaks-note-exercise-1.html )

[FireWood]

Michali schreef op zondag 02 maart 2008 @ 10:44:
Je kunt wel een extra stap maken, maar dan zit je met een extra class waarin al deze properties zitten. Je vector afbeelding class krijgt dan een property van het type van die nieuwe class.

ipv. vectorImage.Rotate wordt het dan bijvoorbeeld vectorImage.TransformOptions.Rotate.

Moet het niet bijvoorbeeld RotateAmount zijn oid.?

RotateAmount is waarschijnlijk beter in deze situatie idd.

Ik heb nu de transform opties wat gereduceerd. Een paar heb ik gecombineerd(uitrekken over de X en Y as of schalen is hetzelfde) en sommige weggegooid, omdat die praktisch toch niet zouden worden gebruikt.

Het zit nu dus nog gewoon in 1 class zoals het hoort.

[Michali]

Zoals het hoort is dan nog maar de vraag. Kijk goed naar de verantwoordelijkheden van je class. Een vector afbeelding heeft namelijk naar mijn idee niet de taak zichzelf te transformeren. Dit soort zaken zou ik toch buiten deze class houden. Dit wilde whoami je ook al duidelijk maken. Let daar wel goed op.

[whoami]

Het zit nu dus nog gewoon in 1 class zoals het hoort.

be-argumenteer dit eens ? Waarom is dat 'zoals het hoort' ?

Misschien moet je eens iets lezen over het 'single responsability principle'.

[PrisonerOfPain]

Michali schreef op zondag 02 maart 2008 @ 10:44:
Je kunt wel een extra stap maken, maar dan zit je met een extra class waarin al deze properties zitten. Je vector afbeelding class krijgt dan een property van het type van die nieuwe class.

ipv. vectorImage.Rotate wordt het dan bijvoorbeeld vectorImage.TransformOptions.Rotate.

Meestal worden deze eigenschappen al gegroepeerd in een aparte transformatie matrix, dus het is enkel logisch om ze samen in een Transformation class te zetten.

Moet het niet bijvoorbeeld RotateAmount zijn oid.?

Angle?

[Michali]

PrisonerOfPain schreef op maandag 03 maart 2008 @ 10:09:
Angle?

Hé, het was zondagochtend, ik had geen zin om daar te veel over na te denken. Amount is iets algemeens, dus kan bijna overal wel gebruikt worden, was maar om als voorbeeld te dienen.

Maar lijkt me idd. wel beter.

[FireWood]

Michali schreef op zondag 02 maart 2008 @ 15:51:
... Een vector afbeelding heeft namelijk naar mijn idee niet de taak zichzelf te transformeren. Dit soort zaken zou ik toch buiten deze class houden. ...

Dit is ook niet de bedoeling. Daar zorgt een render class wel voor. Het gaat mij erom dat ik alle informatie kan opslaan in de class om de render class zijn werk goed te kunnen uit te laten voeren.
Er wordt alleen gecontroleerd op geldigheid van de waarde.

whoami schreef op maandag 03 maart 2008 @ 09:04:
[...]
be-argumenteer dit eens ? Waarom is dat 'zoals het hoort' ?

Misschien moet je eens iets lezen over het 'single responsability principle'.

Ik heb nu 1 class die ik gebruik als een datatype. In de class wordt eigenlijk alleen maar de input gecontroleerd en zo nodig herstelt. In deze class bevindt zich nu alle informatie om het plaatje correct te kunnen renderen op het scherm.
Als de gebruiker nou een voorgedefinieerd tekenobject invoegt op het tekenbord, maak ik een nieuw object aan van deze class: De basis informatie wordt ingevuld en daarna wordt deze toegevoegd aan een array.
Nu kan ik met andere classes alle objecten renderen vanuit deze array en op het tekenbord plaatsen.

De reden dat ik het zo aanpak is de volgende:
Als ik angle e.d. opsla in de data-type class heb ik alle informatie over het object op 1 plek staan.
Hierdoor kan ik de volledige array opslaan en later weer openen. Verder heb ik alle informatie gecentraliseerd, zodat ik rechtlijniger kan programmeren.

PrisonerOfPain schreef op maandag 03 maart 2008 @ 10:09:
[...]

Meestal worden deze eigenschappen al gegroepeerd in een aparte transformatie matrix, dus het is enkel logisch om ze samen in een Transformation class te zetten.
...

Dit was mijn bedoeling ook, maar als ik er een aparte class van maak krijg je dit effect:

code:

Object class
  >TransformObject
Object class
  >TransformObject
Object class
  >TransformObject

Een class die ook rechtstreeks in de Object class kan worden geïnitialiseerd. Een aparte class creëert weer allemaal declaraties en doorverwijzingen, terwijl het niet veel duidelijker geworden is. Nu wou ik tijdens de TS dus de voordelen van een extra stap om de lijsten niet te lang te maken, maar niet de nadelen van een aparte class met declaraties en aanroepen.

De lijst is nu aardig korter geworden door overbodige transform opties weg te halen. De lijst is nu van nette lengte.