What is the right OO implementation?

Hi dear prgrammers, I would like to know which of the following Implementations of an enxemple-Class is the best one:

Solution 1:

class Library < handle

  properties ( Private ) % Here Private !

    address = '';

    books = struct('name', {}, 'author', {});

  end

  methods

    function obj = Library()
    end

    function address = GetAddress(obj)
      address = obj.address;
    end

    function SetAddress(obj, address)
      % check address ist string
      obj.address = address;
    end

    function AddBooks(obj, names, authors)
      % check params (cell arrays of strings)
      obj.books = [obj.books, struct('name', names, 'author', authors)];
    end

    function SetBooks(obj, names, authors)
      % check params (cell arrays of strings)
      obj.books = [];
      obj.AddBooks(names, authors);
    end

    function books = GetBooksField(obj, index, field)
      % (check field in {'name', 'author'})
      books = {obj.books(index).(field)};
    end

    % Eventuell weitere Get.. und Set... für books

  end

end

% Use:
schoolLib = Library();
schoolLib.SetAddress('Mond, 3er Stock');
schoolLib.SetBooks({'a', 'b', 'c'}, {'d', 'e', 'f'});
FirstBookName = schoolLib.GetBooksField(1, 'name');

Solution 2:

class Library < handle

  properties ( Public ) % Here Public !

    address = '';

    books = struct('name', {}, 'author', {});

  end

  methods

    function obj = Library()
    end

    function set.address(obj, address)
      % check address is string
      obj.address = address;
    end

    function set.books(obj, books)
      % check books is struct array with string fields 'name', 'author'
      obj.books = books;
    end

    function AddBooks(obj, names, authors)
      % check params (cell arrays of strings)
      obj.books = [obj.books, struct('name', names, 'author', authors)];
    end

    % Eventuell weitere Get.. und Set... für books

  end

end

% Use:
schoolLib = Library();
schoolLib.address = 'Mond, 3er Stock';
schoolLib.books = struct('name', {'a', 'b', 'c'}, 'author', {'d', 'e', 'f'});
FirstBookName = schoolLib.books(1).name;
schoolLib.books(1).name = 'new name';

Solution 3: make another class for Book... I would like to avoid it for such a simple data. What are the pros and cons (Parameters Public and Private)? Why? Is there a solution in between? Is it important or just a matter of taste? Especially for 'books' (Struct Array) is this question relevant. can we have a Struct Array Parameter Public and unse the native getter & setter on it?

Thand you for sharing your opinion!

[Andrew Newell]

This looks familiar. Have you been reading Unit Test Frameworks by Paul Hamill?

Answer 1

[Adam]

If you are going to write get and set function anyway then there is absolutely no point in making properties private. Just use public and the standard get and set functions as in your second example.

If you wish to do validation against some other class property in your set function then the private approach with a separate setter function would work though personally I use a dependent property and a paired private property for that.

As for any deeper questions of design getting the right object-oriented design for a system is always tricky and there is never a single best answer. It always depends on how you want to use it, whether or not other people will be using what you write without needing to understand the implementation, etc, etc.

As a rule I like to start out with immutable properties with private GetAccess and then only make them public if I find the need to and there isn't some better solution to the problem.

Having a lot of public properties does call into question the validity of your class as an entity sometimes though. If external objects/code have to keep accessing all the internals of your class then what is the class itself doing?

I don't know what the full problem you are trying to solve is so I wouldn't give any more concrete suggestions and especially because they would be a matter of opinion in most cases anyway.

One thing I would say though is that I never use structs in OOP - they just don't seem to make any sense. If you have a concretely-defined set of properties to go together then make them into a class. In that way validation and usage is much better too since a struct is just like a christmas tree that you can hang anything on.