OOP questions

Discussion in 'Programmer's Corner' started by Dritech, Jan 10, 2015.

  1. Dritech

    Thread Starter Well-Known Member

    Sep 21, 2011
    Hi all,

    I am doing an OO program but I'm not sure if encapsulation is being violated.

    When declaring lists (ex: List<listA> people = new List<listA>(); ), are these declared in the main class or in their respective class? also, when loading all the data on start-up of the application, shell this be performed in the main class as well?
    Is it true that the methods must not include a lot of line coding?

    Thanks in advance for your help and sorry for my poor English.
  2. joeyd999

    AAC Fanatic!

    Jun 6, 2011
    Cannot answer your other questions, but I would imagine that the answer to the question "How many lines of code should a method have?" would be "Just enough."
    panic mode likes this.
  3. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    Objects expose data and methods. Generally a method contain all the code required to perform that method.

    Doing something else would be a violation of encapsulation.

    The class defines the data and methods. An instance of the class (when you create an object) is required for each "thing" you make.

    Thus a List class may be used to create multiple lists.
  4. WBahn


    Mar 31, 2012
    As rule, you want to keep function lean, meaning that they are relatively short and do one conceptual thing (or at least only a small number of related things). The idea is to match your function hierarchy to your problem solving hierarchy -- you break your problem, no matter how complex, into a small set of slightly smaller steps that need to be performed. Each of those steps become a function and then you repeat that process taking each step and breaking it into a small set of slightly smaller steps with each of those becoming a function. This continues until you reach steps that can be performed completely in a small amount of code. A good rule of thumb is to try to make functions fit entirely on one screen page so that you can view the entire function as a whole. Sometimes this is not realistic because sometimes, for instance, a function might be conceptually very simple but might involve a case statement with a lot of enumerated cases. But here, even if the listing of the function is several pages long, it is conceptually very simple to understand and examine.
  5. vpoko


    Jan 5, 2012
    I'm not sure I understand what your asking, but you should usually declare variables in the scope where you'll use them. Methods without bodies are used when defining an interface, they require whoever uses the interface to provide the body. An example is creating a sortable class by using the IComparable interface; you'll then need to provide your own comparator function.
  6. darrough


    Jan 18, 2015
    If you are still thinking data/code then you are not doing object oriented. An object is a high level entity. One sends high level messages to an object from other objects. An admittedly simplistic example. A "square" object cannot be instanitated with four points, because the calculations for those points have to be inside the object.
  7. joeyd999

    AAC Fanatic!

    Jun 6, 2011
    This is likely the most opaque description of OOP I've ever read. Congratulations.
    ErnieM likes this.
  8. #12


    Nov 30, 2010
    I'm still thinking, "Order Of the Phoenix" but nobody responds to my Harry Potter references on this site. :(
  9. MaxHeadRoom


    Jul 18, 2013
    Or as R.R. says if you happen to inquire about the H.P. of the engine.
    'Sufficient' ;)
  10. Simon Larsen


    Feb 22, 2015
    It can be both. But the most common thing that you will see is that the list of people is declared outside of the people class. An example could be a data access object reading a list of people from a text file. In that example the data access class will declare the list of people. Use the Parser class to parse the text file and add the people to the list. Sometimes the dataaccess class will keep a copy of the list (for caching purposes) other times it will just create the list - return it - and forget about it.

    It depends on the system and so on (performance considerations and the list goes on...). My advise is to load things when you need them - and if that causes issues I would rethink the architecture in those situations.

    yes. practical advice: above 50 lines is too much. If you go over break the method into smaller parts. Reason: code is easier to read and maintain.