[Year 12 SofDev] Records VS Classes

Brett bpfitz at netspace.net.au
Fri Feb 26 20:07:19 AEDT 2016


Hi all
I'm teaching records combined with arrays - arrays of records using structs in C#. Seemed like a logical approach as whether files are XML, CSV or database records I figure the students will need some way to process data for the SAT. 
Good algorithm practice too.

Sent from my iPad

> On 26 Feb 2016, at 1:32 pm, "Baas, Benjamin B" <baas.benjamin.b at edumail.vic.gov.au> wrote:
> 
> I’m sort of the opposite of you. I’ve only used structs/records when I was programming in C. I never had to use structs/records in OO languages, this is the first time I’ve had to. I’ll be telling my students that because I know I’ll forget the syntax.
>  
> Cheers,
>  
> Ben.
>  
> From: sofdev-bounces at edulists.com.au [mailto:sofdev-bounces at edulists.com.au] On Behalf Of Mark
> Sent: Friday, 26 February 2016 1:21 PM
> To: Year 12 Software Development Teachers' Mailing List <sofdev at edulists.com.au>
> Subject: Re: [Year 12 SofDev] Records VS Classes
>  
> From my dusty memory of Visual Basic, structures and records are related. 
> (I refer to VB STRUCTures, rather than generic SD structures including arrays etc as mentioned in the study design.)
>  
> VB Structures store related fields of data as a single unit in RAM during execution, and records store related fields as a single unit  on disk. Typically, one would read records from a random file on disk and store them in a corresponding custom structure in RAM, which is defined as a class, e.g.
>  
> STRUCT person
>   .GivenName as string * 15
>   .FamilyName as string * 25
>   .dob as date
>   .NumPets as integer
> END STRUCT
>  
> I have vague memories of then instantiating a instance of the class 'person' (e.g. employee, customer) to actually store some data. Fields in the structure could then be addressed with a syntax like customer.GivenName = "Fred".
>  
> While the study design does not refer to this type of RAM-based structure (it only names 1D arrays and records) in real life I always used records and STRUCTures together as a team. I've always considered a structure to be conceptually like a class.
>  
> I'd be interested in hearing more on this issue. I've always avoided classes, inheritance, polymorphism, encapsulation and the like, and lived quite happily without them because SD has never required their use in theory or practice.  Even now, the requirements of a programming language for SD (summarised here) don't require the use of classes.
>  
> It is odd, however, that while classes are not mentioned anywhere in SD U3 or U4, they are referred to in Unit 2!
> The intro to U2AOS1 (p.23) includes the use of "predefined classes"... but then they do not appear anywhere in the U2O1 KK. (What happens when something is required in the AOS discussion, but not in any of the KK or key skills?)
>  
> But, then again, using "predefined classes" could mean nothing more than using GUI objects like textboxes, so it's hardly a conceptual oasis for students. They could use textboxes all day without ever needing to know anything about classes.
>  
> I'd be happy to be corrected about anything I've got wrong in my ramblings.
>  
> Mark
>  
>  
>  
> On 26 February 2016 at 07:52, Baas, Benjamin B <baas.benjamin.b at edumail.vic.gov.au> wrote:
> The study design mentions records under the dot point referring to data structures. To me that sounds like they want to us to look at records with in the programming language. In the case of the C languages and VB struts or structures. That’s my interpretation. I might ask Paula.
>  
> ·         types of data structures, including one-dimensional arrays (single data type, integer index) and records (varying data types, field index)
> 
>  
> Cheers,
>  
> Ben.
>  
> From: sofdev-bounces at edulists.com.au [mailto:sofdev-bounces at edulists.com.au] On Behalf Of Paragreen, Chris J
> Sent: Thursday, 25 February 2016 3:40 PM
> To: Year 12 Software Development Teachers' Mailing List <sofdev at edulists.com.au>
> Subject: Re: [Year 12 SofDev] Records VS Classes
>  
> My interpretation is that we need to teach records as in files and records, as opposed to the language specific data structure. How you then implement the record is up to … you? … the students? I’m also thinking that might tie into XML and the importing and exporting of data. Please tell me if my interpretation is wrong!
>  
> Chris
>  
> From: sofdev-bounces at edulists.com.au [mailto:sofdev-bounces at edulists.com.au] On Behalf Of Laurie Savage
> Sent: Thursday, 25 February 2016 2:03 PM
> To: Year 12 Software Development Teachers' Mailing List <sofdev at edulists.com.au>
> Subject: Re: [Year 12 SofDev] Records VS Classes
>  
> Always a good idea to teach what is in the study design even if current practice is moving past it.
>  
> Laurie Savage
> PVGC
> 
> Laurie Savage
> https://sites.google.com/a/pvgc.vic.edu.au/mr-savage/home
>  
> On 25 February 2016 at 13:15, Baas, Benjamin B <baas.benjamin.b at edumail.vic.gov.au> wrote:
> Hi all,
>  
> I just wanted to get people’s opinions, as part of the study design we have to teach our students  about record data structures. If we have to use an OO language would it not be best to just teach them how to make classes.
>  
> I haven’t done structs in C# before, only C, and to me it feels like I should just teach me students how to make basic classes and not worry about teaching sturcts. I will teach them structs as that’s what the study design says.
>  
> Cheers,
>  
> Ben.
>  
> Benjamin Baas
> <image001.png> Alkira Secondary College
> +   Nurture Ave, Cranbourne North | PO Box 4314, Narre Warren South 3805
> '   +61 3 5991 3500      6 +61 3 5991 3599     8 www.alkirasecondarycollege.com.au
> Alkira Secondary College believes in Personalised learning for all, and  Respect for the individual
>  
> IMPORTANT - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Training.
> IMPORTANT - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Training.
>  
> IMPORTANT - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Training.
>  
> IMPORTANT - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Training.
> 
> _______________________________________________
> http://www.edulists.com.au - FAQ, Subscribe, Unsubscribe
> IT Software Development Mailing List kindly supported by
> http://www.vcaa.vic.edu.au - Victorian Curriculum and Assessment Authority and
> http://www.vcaa.vic.edu.au/vce/studies/infotech/softwaredevel3-4.html
> http://www.vitta.org.au  - VITTA Victorian Information Technology Teachers Association Inc
> http://www.swinburne.edu.au/ict/schools - Swinburne University
> 
> 
>  
> --
>  
> Mark Kelly
>  
> mark at vceit.com
> http://vceit.com
> Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Training.
> 
> _______________________________________________
> http://www.edulists.com.au - FAQ, Subscribe, Unsubscribe
> IT Software Development Mailing List kindly supported by
> http://www.vcaa.vic.edu.au - Victorian Curriculum and Assessment Authority and
> http://www.vcaa.vic.edu.au/vce/studies/infotech/softwaredevel3-4.html 
> http://www.vitta.org.au  - VITTA Victorian Information Technology Teachers Association Inc
> http://www.swinburne.edu.au/ict/schools - Swinburne University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.edulists.com.au/pipermail/sofdev/attachments/20160226/026f5e89/attachment-0001.html 


More information about the sofdev mailing list